如何排查Windows Server 2016上IIS 10.0应用池随机重启问题？

我们有一台运行IIS 10.0的Windows Server 2016服务器，托管多个应用池。其中某高负载应用池会随机重启，导致站点短暂无响应，客户端需重新认证，伴随数百个ASP会话重载及数千个SignalR连接重建，之后恢复正常。进程未被终止或崩溃，承载该池的w3wp进程运行时长未归零，更接近回收操作，每日发生3-6次，需找出重启原因并解决。

已排查并排除的潜在原因 #

• 已排除空闲超时（idle timeout）：站点处于高负载状态，且已禁用空闲超时配置
• 已排除每日自动回收（automatic daily recycle）：该功能已禁用
• 已排除文件配置变更（file configuration change）：已在web.config中添加fcnMode="Disabled"，且其他站点未出现重启，排除全局IIS文件变更影响
• Windows事件日志各分类未发现相关事件记录
• inetpub\logs\LogFiles\W3SVC1及iislogs\www\HTTPERR日志中未找到重启相关信息
• 已添加System.Web.Hosting.HostingEnvironment.ShutdownReason日志，暂未获取有效信息

新增排查思路与日志启用方案 #

一、启用更详细的IIS回收日志 #

• 开启应用池回收事件日志：在IIS管理器中选中目标应用池，进入「高级设置」→「回收」，勾选「生成回收事件日志条目」，并确保所有回收触发条件的日志选项都被启用，重启应用池后生效。
• 启用进程模型日志：在应用池「高级设置」的「进程模型」板块，开启「日志事件」，记录进程启动/停止的详细触发原因。

二、排查易被忽略的应用池回收触发配置 #

• 检查内存限制回收：查看应用池「回收」项下的「私有内存限制」「虚拟内存限制」，高负载场景下可能因内存触及阈值触发回收，即使未手动设置，系统默认也可能存在隐性阈值。
• 检查请求数限制回收：确认「每N个请求回收」是否被误启用，部分场景下该配置可能被无意开启。
• 检查CPU限制回收：查看「CPU」板块的「动作」是否设置为「回收」，若CPU使用率超过设定阈值，会触发应用池回收。
• 检查自定义计划回收：除每日自动回收外，查看「回收」选项中的「特定时间」，是否存在自定义的回收计划任务。

三、排查应用程序内部触发的回收 #

• 检查代码逻辑：排查ASP.NET应用中是否存在手动调用HttpRuntime.UnloadAppDomain()或其他触发应用域卸载的代码，高负载场景下这类逻辑可能被触发。
• 排查第三方组件：临时禁用非必要的第三方IIS模块或应用依赖组件，观察是否仍出现重启，排除组件触发回收的可能。

四、用性能监控工具追踪诱因 #

• 性能监视器（PerfMon）：添加以下计数器，监控重启前后的指标变化：
  • ASP.NET Applications：应用域重启次数、会话数量
  • IIS App Pools：回收次数、进程内存使用
  • Process：w3wp进程的CPU、内存、句柄数
• DebugDiag工具：捕获w3wp进程的内存dump，分析重启前是否存在内存泄漏、资源耗尽等情况，定位触发回收的根源。

五、排查系统层面影响因素 #

• 检查Windows更新：确认近期是否安装了Windows或IIS相关更新，部分更新可能调整了应用池回收机制。
• 检查系统资源：排查服务器是否存在磁盘空间不足、系统内存耗尽等情况，这类问题可能间接触发应用池回收。
• 检查安全工具：临时关闭杀毒软件的实时扫描功能，排除其误操作IIS文件或进程导致的回收。

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