几天前，我一直在调查 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。它连接到远程数据库，但其他方面独立于其他机器。
答案1
你看过全球HTTP 错误日志？
它被称为并且通常位于主服务下的httperr.log日志文件目录中。C:\windows\system32\LogFilesW3CSVC1
每当我遇到应用程序池问题时，该文件总是很有帮助。
答案2
IIS 中的“Ping”只是 W3SVC 执行的一项健康检查，用于监控工作进程的状态。当您看到诸如“为应用程序池‘appPool’提供服务的进程未能响应 ping”之类的事件时，表示该进程处于死机状态。
快速失败保护是一种回收选项，它可以处理此类问题并自行回收 appPool，以保持工作进程的良好运行。
您需要调试该过程来找到问题的根源。
由于您在工作进程中加载了 .net 应用程序，因此检查应用程序事件日志并查看是否有任何 .net 框架警告或错误是个不错的主意。您可以将调试诊断工具附加到该进程并进行转储以检查导致问题的原因。关注文章如何使用调试诊断工具对 IIS 中已停止响应的进程进行故障排除