IIS应用池10个工作进程请求分配异常，CPU负载不均求解决

1. 关闭会话亲和性（粘性会话） #

默认情况下IIS会启用会话亲和性，同一个用户的所有请求会被固定分配到同一个工作进程，这是单进程负载过高最常见的原因。

• 操作步骤：
  1. 打开IIS管理器，定位到目标应用池
  2. 右键选择「高级设置」
  3. 在「进程模型」分类下，将「会话亲和性」设置为 False
  4. 重启应用池生效

2. 排查进程内状态依赖 #

如果应用代码依赖进程内存储（比如静态变量、MemoryCache、进程内会话），请求会被逻辑绑定到同一个进程——其他进程没有对应状态数据，自然无法分担负载。

• 解决措施：
  • 将进程内状态迁移至分布式存储（如Redis、SQL Server缓存）
  • 改用分布式会话模式，脱离对单个进程的依赖

3. 定位高CPU进程的慢请求 #

单个进程CPU持续维持在30%-40%，大概率是在处理长耗时请求（如慢SQL查询、同步IO操作、复杂计算逻辑），导致无法及时处理新请求，同时IIS分发逻辑可能持续向该进程推送请求。

• 排查方法：
  • 启用IIS「请求跟踪」功能，捕获响应超时的请求，分析具体瓶颈
  • 使用Process Explorer查看该w3wp.exe进程的线程栈，直接定位CPU占用高的代码逻辑
  • 检查应用是否存在死锁、线程阻塞情况，导致进程资源无法释放

4. 验证多进程配置有效性 #

先确认多进程配置是否真的生效：

• 打开任务管理器，筛选w3wp.exe进程，右键添加「命令行」列，查看进程对应的应用池名称，确认是否有10个进程在运行
• 检查应用池高级设置中「最大工作进程数」是否确实设为10，同时将「启动模式」设为AlwaysRunning（避免按需启动导致进程未全部激活）
• 若进程数量不足，尝试重启应用池或服务器，排查是否存在权限限制（如应用池标识无足够权限启动多进程）

5. 调整负载分配算法 #

默认的轮询分配模式会被会话亲和干扰，关闭亲和性后仍存在负载不均的话，可尝试更换负载模式：

• 进入应用池高级设置→「进程模型」→「负载均衡模式」，可选：
  • LeastRequest：将请求分配给当前请求数最少的进程，通常能有效改善负载不均
  • WorkerRequest：基于进程处理能力动态分配请求
• 优先尝试LeastRequest模式

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