我在带有访问数据库的Win2012R2上一堆(约50个)经典ASP站点遇到问题,这使我们发疯。
此服务器上所有站点的所有asp页均在大约45秒钟内平稳运行,在此之后,它们(全部)在15到20秒钟内完全停止响应任何点击,然后此延迟在接下来的45秒钟内再次消失,例如它以前从未存在过,再次出现-依此类推。经过几个月没有出现任何问题,这种效果几周前才开始出现。
静态HTML页面不会受到影响,而且即使没有连接到数据库的asp页面也可以正常运行。因此,我们尝试进行测试,以将Access从Access转换为SQLExpress,但这并没有任何改变-即使转换后的网站也以相同的方式受到影响(因此似乎不是Access)。
然后,我们尝试停止IIS中的所有站点,并仅在只有很少访问者的情况下重新激活一个站点,以查看是否在许多请求发送到服务器时它仅出现。但是,即使在重新启动IIS之后,甚至在仅在IIS中激活了一个网站的情况下重新启动整个计算机之后,效果仍然显示出来。它似乎完全独立于效果的数量,就像服务器(而不是IIS的asp引擎)以周期性模式忙于自身一样。
我们在性能监视器中看到的内容(请参见屏幕截图):虽然请求/秒有时会降低到0,但效果开始时,执行的请求数会从正常水平(从“逻辑”到我,但仅描述其效果,而不是说明其来源)。效果消失前几秒钟,请求/秒再次增长,并且这些计数器恢复为正常值。
一年前,我们在Windows 2008-Server上遇到了类似的问题,该站点运行了好几年都没有任何问题,然后从零开始。在另一台托管服务器的服务器上测试了某些站点之后,我们发现,问题没有出现在他的Windows 2012 R2服务器上(并且在整整一年内都没有出现,而在那托管了3个站点)。在另一台虚拟Windows 2012R2-Server托管服务器上,我们拥有另一个站点托管的流量比我们其他大多数站点都多,甚至直到整整一年都没有出现问题。因此,我们的托管人切换到WinServer2012R2,并且-宾果游戏-所有问题都消失了。从那时起,所有站点都再次表现出魅力,除了操作系统外没有任何改变。
然后我们停止调查此问题,认为该问题与操作系统有关。但是大约9个月后,它又出现了,经过数小时的调查,我们不知道要搜索什么和做什么(除了将所有站点移至其他主机服务器之外,这不是一个真正的解决方案)对于该问题,我们不能保证,将来这种效果有时不会再次出现在这台机器上。
答案 0 :(得分:0)
我最终以一种完全随机的方式找到了自己的解决方案。在寻找问题解决方案数周之后,我致力于清理服务器的硬盘并删除Windows / temp-folder中的所有文件(> 18.000个文件!)。并且从这一刻开始(4天前),描述的响应滞后再也没有出现!但是,在该文件夹中创建了一小堆新的.tmp文件。
我的理论是:也许每次用户访问一个网站(打开与其Access数据库的连接,在数据库文件夹中导致一个.ldb文件),一个随机的(?)名为.tmp文件(例如:jet12f0.tmp)在Windows / temp文件夹中并行创建。随着数据库连接关闭和.ldb消失,这些文件将再次“正常”删除。也许某些连接未正确关闭,因此Windows / temp文件夹中的相应.tmp文件作为“孤儿”驻留在那里,字面永远。随着时间的流逝,文件夹中充满了这些孤立的文件。然后,应该生成一个新的.tmp文件,但其名称仍然是一个“孤立的” .tmp文件。现在,这将导致服务器停止所有操作,因为无法建立新文件(命名为现有文件)。 15至20秒后,通过某种机制(我不知道)解决了冲突,所有冲突再次完美运行,直到大约45秒后出现下一个冲突。等等...
我必须假设:这只是一个“业余”理论,我不是服务器的“大师”。
由于不存在文件/命名冲突,因此不时清理此临时文件夹似乎可以防止服务器陷入这种情况。
我同意:真正的解决方案是在代码中查找问题(如果有的话),但我们可以忍受这种情况,将查找问题的工作与仅清理一次临时文件夹进行比较即可。一个月左右;-)