IIS应用池工作进程堆积、卡在启动状态问题求助

针对你遇到的这个棘手问题——明明配置了单工作进程的IIS应用池，却堆积了29个进程还导致CPU持续满载，结合你的环境和现象，我整理了几个实用的排查和解决方向：

一、先揪出旧进程无法退出的根源 #

你的应用池启用了重叠回收（禁用重叠回收设为False），正常逻辑是新进程启动后，旧进程处理完现有请求就会退出，但现在旧进程卡住了，这是核心问题：

• 用Process Explorer分析线程栈：打开卡住的旧进程，查看每个线程的调用栈，重点找有没有阻塞的操作——比如等待数据库锁、死锁、调用外部服务超时未释放，或者WCF请求卡在某个环节。
• 抓取Dump文件分析：用DebugDiag或者Windbg给卡住的进程拍个dump，分析是否存在死锁、未完成的异步操作，或者资源泄漏（比如未关闭的文件句柄、数据库连接）。
• 开启WCF跟踪日志：在web.config里配置system.diagnostics节点，启用WCF的请求跟踪，看看回收时间点前后有没有长时间未完成的请求，这些请求很可能就是拖垮进程退出的元凶。

二、调整回收配置临时缓解 #

先解决进程堆积的燃眉之急，再深入排查根源：

• 临时禁用重叠回收：把“禁用重叠回收”设为True，这样IIS会先关闭旧进程再启动新进程，避免进程堆积。注意这会导致短暂的服务中断，要提前和客户沟通好时间窗口。
• 检查回收调度的准确性：你设置的特定时间回收是02h00，但出现进程提前3秒启动的情况，可能是系统时钟偏差或者IIS调度的小bug。可以暂时换成固定时间间隔回收（比如24小时），看是否还会出现异常启动的情况。
• 调整进程关闭超时：IIS默认给旧进程90秒时间退出，如果你的服务有长耗时请求，这个时间可能不够。可以在应用池的“回收”设置里调大“关闭超时”（比如设为300秒），或者极端情况下勾选“立即终止”（但这可能导致未完成的请求丢失，谨慎使用）。

三、排查权限和系统环境问题 #

• 验证应用池身份权限：你的应用池用的是domain\account，要确认这个账号拥有SeDebugPrivilege权限，否则IIS可能无法正常终止旧进程。可以通过本地安全策略给账号添加这个权限。
• 检查系统资源和补丁：
  • 看看服务器的磁盘IO、内存是否正常，如果磁盘读写慢，进程退出时清理资源、写日志都会卡住；
  • 你的Windows Server 2016版本是14393.3443，微软之前修复过一些IIS应用池回收的bug，建议安装最新的累积更新，说不定能解决这个特定版本的问题。

四、针对WCF服务的特殊排查 #

因为你的应用池跑的是WCF服务，有几个点要重点查：

• 检查Application_End逻辑：如果Global.asax里的Application_End事件有长时间运行的代码（比如批量清理、日志上传），会导致进程无法正常退出，把这些逻辑改成异步或者缩短执行时间。
• 验证WCF实例/并发模式：如果用了单实例模式，或者并发设置不合理，可能导致请求排队，进程无法退出。检查WCF服务的配置，确保实例模式和并发模式符合业务需求，并且没有资源泄漏。
• 排查未释放的资源：WCF服务里有没有未关闭的数据库连接、网络连接、文件流？这些资源泄漏会让进程无法正常关闭，用内存分析工具（比如dotMemory）检查资源占用情况。

五、监控验证，确认解决效果 #

• 启用性能计数器：监控IIS的Application Pool计数器（比如进程数、请求队列长度）和WCF的ServiceModel计数器（比如请求数、错误数），实时跟踪回收前后的状态。
• 对比手动和自动回收：手动回收正常但自动回收出问题，说明可能是自动回收的触发条件或者环境差异导致的。可以在自动回收时段远程监控，看系统当时有没有其他定时任务（比如备份、杀毒）干扰。

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