IIS应用程序池闲置超时最大值问题及设置后重启原因排查

关于Idle Time-out最大值的确认 #

Windows Server 2012 IIS 8.0中，应用程序池Idle Time-out (minutes)的最大值为4294967295分钟（约8171年），你设置的10080分钟（7天）远未达到上限，因此该值不是此次意外重启的原因。

具体排查步骤 #

• 确认Idle Time-out配置生效

  1. 打开IIS管理器，定位目标应用程序池，右键选择「高级设置」，核实Idle Time-out (minutes)为10080，且Idle Time-out Action为默认的「Terminate」。
  2. 用命令行验证：打开命令提示符，执行

     %windir%\system32\inetsrv\appcmd list apppool "你的应用程序池名称" /text:processModel.idleTimeout
     

     正常返回值应为07.00:00:00（对应7天超时）。

• 检查其他自动重启触发条件
  IIS应用程序池重启的触发条件远不止Idle Time-out，重点排查以下配置：

  • CPU限制：查看「高级设置」→「CPU」，确认Limit (percent)是否设置过低，且Limit Action为「KillW3wp」（CPU超限会强制终止进程）。
  • 内存限制：查看「高级设置」→「Recycling」，检查Private Memory Limit (KB)和Virtual Memory Limit (KB)，若进程内存超出阈值会自动回收应用程序池。
  • 定时回收：「Recycling」下的Regular Time Interval (minutes)默认1740（29小时），若被修改为更小值可能触发回收；同时检查「Specific Times」是否设置了定时回收任务。
  • 请求数限制：「Recycling」下的Request Limit，若累计请求数达到设定值会触发回收。

• 通过日志定位具体原因

  1. 打开「事件查看器」→ 「Windows日志」→「系统」，筛选来源为WAS（Windows Process Activation Service）的事件：
     • Event ID 5074：记录应用程序池回收的具体触发原因（如内存超限、定时回收等）。
     • Event ID 5011：记录进程意外终止的信息，可排查是否为应用崩溃导致。
  2. 查看「应用程序日志」，检查是否存在未处理的.NET异常或应用级错误，这类错误可能导致w3wp.exe进程崩溃，进而触发应用程序池重启。

• 排查外部干预因素

  • 检查服务器上的计划任务，确认是否有定时脚本或工具强制重启应用程序池/w3wp.exe进程。
  • 核实杀毒软件或安全工具是否误将w3wp.exe判定为恶意进程并终止。

• 验证配置变更兼容性
  临时将Idle Time-out (minutes)改回原设置1440，观察2小时内是否仍出现重启，以此排除配置变更引发的潜在兼容性问题。

内容的提问来源于stack exchange，提问作者Koops128