服务器规格
Microsoft Windows Server 2003 Enterprise Edition SP2
IIS 6
.NET4
Intel（R）Xeon（R）CPU X5680 @ 3.33GHz，2.00GB RAM 物理地址扩展
我无法找到服务器随机停机的原因。我们的客户告诉我们他们的网站一次下降几个小时。有时用户可以登录，但网站极其缓慢/不稳定且无法使用。有时用户根本无法登录。当用户能够登录时，并非所有图像都显示（他们得到图像未找到图像）。
我们将他们的网站从.net1升级到.net4，因为我们认为他们停机和随机用户注销的原因是他们在.net1上运行他们的网站。该网站运行良好，几个月没有任何问题。
此后服务器第一次开始关闭是由于网站停留在磁盘空间不足的驱动器。此驱动器分区为40GB，并添加了20GB。这并没有解决这个问题很长时间。
第二次服务器随机关闭时，我注意到在事件查看器中，与网站使用的应用程序池相关联的Web工作者会定期要求重新列入。也就是说，在事件查看器的“安全”选项卡中，我会定期看到一个ID为1074的事件，该事件的进程ID为＆＃39; 1540＆＃39;服务应用程序池＆＃39; Net4＆＃39;已要求回收，因为工人流程达到了允许的处理时限。＆＃39;。然后我进入了这个应用程序池的属性，看到应用程序池将每29小时回收一次，这是默认设置。我修改了这个以使应用程序池每天凌晨3点回收。因为我们在事件查看器中没有看到此事件。在更改网站之前，我们能够在其中一个停机时间内抓住网站，并手动回收应用程序池。这解决了这一问题。
然而，这并没有永久性地解决问题，因为我们仍然收到客户发来的电子邮件，告知我们网站一次停机数小时。
然后我设置了一个性能监视器计数器日志。我们设法在许多停机期间监控服务器的性能。它似乎没有内存问题，因为驱动器上有足够的空间。它似乎不是内存泄漏或与过度分页相关，因为没有正在运行的进程占用过多的处理器时间，并且页面/秒内存计数器在大多数停机时间内没有达到过高的峰值（我将解释为什么以后会发生过多的分页。在停机期间，总IO数据字节数/秒和IO其他数据字节数/秒过程计数器通常不会显示为高或低。总螺纹计数和手柄计数过程计数器在此期间不会出现任何异常尖峰或下降。在给定时间，总线程数似乎在600到900之间，给予或接受。在给定时间，总手柄数似乎在15,000到23,00之间，给予或接受。例如w3wp的Jit .NET CLR jit计数器中的％Time在大约一半的时间内为0并且将在近一半的时间内随机达到峰值，大部分时间达到峰值但很少达到峰值大约10分钟，无关停工。
整天都有随机时间，进程dsmcsvc占用了％Processor Time的大部分（如果不是全部）。这是Symantec Antivirus软件运行的过程。当此过程占用处理器时间百分比时，事件查看器中存在相应的事件，表示已上载新的病毒定义文件，即已加载ID 7＆＃39;新病毒定义文件的应用程序事件。版本：#version number＃＆＃39;。发生此事件时，Pages / Sec计数器出现峰值。有时它的峰值只有200-300，但有时会超过10,000。此事件似乎与网站停机时间完全无关。我研究了Symantec Antivirus软件，发现该软件的旧版本中存在已知的内存泄漏。我发现，当一个名为NavLogon.exe的进程的链接被破坏/不存在时，已知该软件会导致高内存使用率。此过程似乎不存在于服务器上，因此我目前无法恢复到它的链接。我还发现这个软件使用Crypt32.dll，旧版本的Crypt32.dll有一个已知的内存泄漏。服务器上存在的Crypt32.dll最后一次更新于2007年。
性能监视器日志监视总会话活动ASP.Net应用程序计数器。在停机期间，会话总数不会出现任何异常行为，在此期间会有正常数量的活动会话。在给定时间的活动会话可以在0到200之间。我被告知大多数用户活动的时间是第一班，但是在每天晚上10点和凌晨2点，这个数字达到峰值。
该站点运行JavaScript客户端和Visual Basic.net服务器端。所有用户几乎在所有时间都有大约10-15个会话变量。
当网站发生故障时，没有任何事件似乎与事件查看器中的停机时间相对应。
我还为此站点设置了W3C扩展日志文件格式日志。在停机期间，Telerik.RadUploadProgressHandler.ashx似乎有过多的GET请求。
此时我已经认真地用尽了想法，并在网上广泛搜索了解决方案并且空洞。关于为什么会发生这种情况的任何反馈都会很棒。
答案 0 :(得分：0)
由于驱动器上有足够的空间，因此内存似乎没有问题。
真的？内存和硬盘空间是两个完全不同的东西。十年前，当该服务器是新服务器时，2GB内存是可以的，但今天它可笑的很小。
但不要打扰升级或添加RAM。这台服务器足够老，问题可能只是硬件达到了使用寿命的终点。此外，操作系统也接近它的寿命终结。 Server 2003计划于2015年7月14日结束。在该日期之后，将不会为Server 2003生成任何类型的新补丁...甚至不是关键的安全补丁。这将使Server 2003完全不适合作为Web服务器。
这似乎是执行向全新服务器转换的好时机。