我一直在调查几天前在 Windows 2003 服务器上发生的一个问题。大约有 15 个应用程序池，在几分钟内，它们都在系统日志中产生了以下错误：
A process serving application pool 'Pool 31x' failed to respond to a ping. The process id was '7144'.
然后池会自动重新启动，但在启动过程中会超时，导致所有站点都关闭。
我的问题是：什么会导致所有应用程序池在同一时间出现“ping 超时”，然后为什么它们启动太慢？
每个池中的应用程序都是使用 .NET 1.1 框架的 WCMS。它连接到远程数据库，但在其他方面独立于其他机器。
您查看过全局HTTP 错误日志吗？
它被调用
httperr.log并且通常位于C:\windows\system32\LogFiles主W3CSVC1服务下的日志文件目录中。每当我遇到应用程序池问题时，该文件都会很有帮助。
IIS 中的“Ping”只不过是 W3SVC 进行的健康检查，用于监控工作进程的状态。当您看到诸如“服务应用程序池‘appPool’的进程未能响应 ping”之类的事件时。表示进程处于死亡状态。
快速故障保护是一种回收选项，它处理此类问题并自行回收 appPool 以保持工作进程的良好运行状况。
您将需要调试该过程以找到问题的根源。
由于您在工作进程中加载了 .net 应用程序，因此检查应用程序事件日志并查看任何 .net 框架警告或错误并不是一个坏主意。您可以将调试诊断工具附加到进程并进行转储以检查导致问题的原因。按照文章如何使用调试诊断工具对 IIS 中停止响应的进程进行故障排除