昨天凌晨 2:17，香港柴湾机房。NOC 值班群又响了：w3wp.exe 内存 5.2GB，API 超时 > 30s。

我盯着 Zabbix 的曲线，像看着一根缓慢上升却永远回不去的心电图。熟悉的味道——又是内存泄露。

我知道，今晚要和 IIS 应用池好好谈谈了。

下面是我在 Windows Server 2008 / 2008 R2（IIS 7.0/7.5）环境下，专门为“高频内存泄露”设计的一套可复制的 实操优化与排障打法。写得尽量细：从现场环境、参数表、命令到坑点复盘，既能救火，也能留下可复用的 Runbook。

1. 现场环境与基线

1.1 机房 & 硬件（实配样例）

注：2008 = IIS 7.0，2008 R2 = IIS 7.5。两者在管理界面细节略有差异，但本文命令全部使用 appcmd，通用。

1.2 症状与基线数据

我们遇到的是典型“齿轮锯”型增长：w3wp.exe Private Bytes 持续上升，不随 GC 回落，最终触发 OOM 或被回收。基线一小段真实数据（20:00–02:00）：

经验判断：

• Gen 2/LOH 趋势性增长 + GC 比例上升，但内存不回落 → 高概率托管对象被引用链卡住或非托管泄露。
• Handle Count 同步增长 → 可能叠加 GDI/句柄泄露 或第三方库释放不当。

2. 思路总览：先止血，再查因

止血（IIS 应用池层面）：

• 设置私有内存/虚拟内存阈值触发可控回收；
• 配置定时回收 + 交叠回收（Overlapped Recycling），降低尖峰风险；
• 启用**孤儿化进程（Orphan）**并自动抓 Dump；
• 调整 Ping/Rapid-Fail、队列长度、启动/关闭时间；
• 视情况开启 32 位进程限制地址空间，更快触发回收（应急策略）。

查因（定位泄露源）：

• ProcDump/DebugDiag 条件触发抓取 Dump；
• WinDbg + SOS / DebugDiag Analyzer 分析对象根、句柄、非托管分配；
• 针对命中模块给出代码级修复（using/Dispose、Marshal.FinalReleaseComObject、GC.AddMemoryPressure 等）。
• 关键点：止血策略必须“平滑 + 可观测 + 可回滚”。只靠“时间回收”是脆弱的；事件驱动回收更稳。

3. IIS 应用池止血配置（一步到位的参数与命令）

以下命令均在 管理员命令行下执行，路径为 %windir%\system32\inetsrv\appcmd.exe。

假设应用池名：AppPool_ProdApi

3.1 打开观测与日志（别盲飞）

REM 回收事件日志，便于定位触发原因
appcmd set apppool "AppPool_ProdApi" /recycling.logEventOnRecycle:"Time,Schedule,Memory,PrivateMemory,ConfigChange,IsapiUnhealthy,OnDemand"

REM 增大应用池队列（高并发峰值时避免 503）
appcmd set apppool "AppPool_ProdApi" /queueLength:20000

3.2 基于内存的回收阈值（核心）

建议从保守值开始，逐日微调。

REM 私有内存阈值（KB）
appcmd set apppool "AppPool_ProdApi" /recycling.periodicRestart.privateMemory:3500000

REM 虚拟内存阈值（KB）（可选，防止 address space 撑爆）
appcmd set apppool "AppPool_ProdApi" /recycling.periodicRestart.memory:8000000

原则：以 Private Bytes 为主、Virtual Bytes 为辅。Private 触发一般更贴近泄露“实耗”。

3.3 定时 + 交叠回收

我们在 03:40、07:10、14:30、23:55 做轻量定时回收（避开支付/促销波峰）。

保留交叠回收（Overlapped Recycling，默认开启），让新旧 w3wp 并行短暂接棒，避免瞬间 502。

REM 清空既有回收计划（谨慎执行）
appcmd set apppool "AppPool_ProdApi" /recycling.periodicRestart.schedule.clear:true

REM 添加多时间点
appcmd set apppool "AppPool_ProdApi" /+recycling.periodicRestart.schedule.[value='03:40:00']
appcmd set apppool "AppPool_ProdApi" /+recycling.periodicRestart.schedule.[value='07:10:00']
appcmd set apppool "AppPool_ProdApi" /+recycling.periodicRestart.schedule.[value='14:30:00']
appcmd set apppool "AppPool_ProdApi" /+recycling.periodicRestart.schedule.[value='23:55:00']

REM 确保不要禁用交叠回收
appcmd set apppool "AppPool_ProdApi" /recycling.disallowOverlappingRotation:false

REM 平滑退出时间（避免“杀进程”）
appcmd set apppool "AppPool_ProdApi" /processModel.shutdownTimeLimit:00:02:00
appcmd set apppool "AppPool_ProdApi" /processModel.startupTimeLimit:00:02:00

有负载均衡（F5/NGINX/ALB）的，别忘了开启连接耗尽/排水（connection draining），让旧进程自然清空连接。

3.4 孤儿化进程 + 自动 Dump（定位的子弹）

当 IIS 认为进程不健康并要终止时，不直接杀，先把它标为**孤儿（orphan）**并执行抓包命令。

REM 启用孤儿化
appcmd set apppool "AppPool_ProdApi" /failure.orphanWorkerProcess:true

REM 配置抓 Dump 的命令（以 ProcDump 为例）
appcmd set apppool "AppPool_ProdApi" /failure.orphanActionExe:"C:\Tools\procdump.exe"
appcmd set apppool "AppPool_ProdApi" /failure.orphanActionParams:"-accepteula -ma %1 -x C:\dumps"

• %1 会被替换为 w3wp 的 PID。
• -ma 抓完整内存，-x 指定输出目录并创建额外的日志。

3.5 健康探测与快速失败保护

REM Ping 机制（30s 一次，超时 90s）
appcmd set apppool "AppPool_ProdApi" /processModel.pingingEnabled:true
appcmd set apppool "AppPool_ProdApi" /processModel.pingInterval:00:00:30
appcmd set apppool "AppPool_ProdApi" /processModel.pingResponseTime:00:01:30

REM Rapid-Fail（5 分钟内 5 次崩溃就降级保护）
appcmd set apppool "AppPool_ProdApi" /failure.rapidFailProtection:true
appcmd set apppool "AppPool_ProdApi" /failure.rapidFailProtectionInterval:00:05:00
appcmd set apppool "AppPool_ProdApi" /failure.rapidFailProtectionMaxCrashes:5

3.6 32 位进程（应急选项，不做常态）

在 64 位 OS 下启用 32 位应用池，会把可用地址空间压缩到 ~1.2–1.4GB 区间，更快触发回收，从而“以退为进”。但吞吐、内存碎片、某些库兼容性可能受影响，仅用于短期兜底。

appcmd set apppool "AppPool_ProdApi" /enable32BitAppOnWin64:true

4. 预热与冷启动优化（避免回收引发“雪崩”）

IIS 7.5 可安装 Application Initialization 模块做预热；

IIS 7.0（2008）没有官方预热模块，可用计划任务 + curl 或 在回收脚本中自请求关键接口进行预编译与缓存填充。

示例：回收后 10 秒，打预热 URL

REM schtasks 定时命令（示例）
schtasks /create /tn WarmUp_Api /tr "cmd /c timeout 10 && curl http://127.0.0.1:80/api/ping" /sc ONSTART /ru SYSTEM

如果Session 使用 InProc，回收会丢会话。生产必须改为 StateServer/SQLServer，或由网关做粘性会话。

5. 自动化抓 Dump（条件触发），配合分析

5.1 按内存阈值抓取（ProcDump）

REM 当 w3wp Private Bytes 超过 3.6GB 时抓 3 份 dump，每份间隔 30s
procdump -accepteula -ma -s 30 -n 3 -p w3wp.exe -m 3600 -o C:\dumps

5.2 DebugDiag 策略（GUI 简单、报告清楚）

选择 Memory and Handle Leak 模板；

绑定到目标 AppPool；

设置 Private Bytes 阈值或句柄数阈值；

生成报告看 泄露对象增长曲线和可疑调用栈。

5.3 初步分析要点（WinDbg + SOS）

.loadby sos clr            ; .NET 4 用 clr，.NET 2/3.5 用 mscorwks
!eeheap -gc                ; 看堆分布，LOH/Gen2 趋势
!dumpheap -stat            ; Top 类型分布，查“大户”
!gcroot <obj>              ; 反查引用根
!handle -a                 ; 句柄分析（GDI/User/文件/Registry）

如果看到大量 System.Byte[]、String、Bitmap、第三方 PDF/Excel 类、或 COM 互操作对象长期滞留，高度可疑。

6. 代码侧修复动作（命中后立改）

6.1 规范释放（IDisposable）

// 典型：第三方 PDF/Excel/图像库
using (var doc = new PdfDocument())
{
    // ...
} // 自动 Dispose

6.2 COM 互操作彻底释放

var comObj = CreateComSomething();
// 使用...
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(comObj);
comObj = null;

6.3 非托管内存占用告知 GC

var ptr = Marshal.AllocHGlobal(size);
try
{
    GC.AddMemoryPressure(size);
    // ... 使用 ptr
}
finally
{
    Marshal.FreeHGlobal(ptr);
    GC.RemoveMemoryPressure(size);
}

6.4 GDI 对象回收

using (var bmp = new Bitmap(w, h))
using (var g = Graphics.FromImage(bmp))
{
    // 绘制...
} // Graphics、Bitmap 均被释放

6.5 缓存上限与过期

var policy = new CacheItemPolicy
{
    SlidingExpiration = TimeSpan.FromMinutes(10)
    // 或者 AbsoluteExpiration
};
cache.Add(key, value, policy);

7. 运维 Runbook（落地可执行）

7.1 每日巡检（5 分钟版）

tasklist /fi "imagename eq w3wp.exe" /fo list：记录 PID、内存；

appcmd list wp：PID ↔ 应用池映射；

PerfMon 快照：Private Bytes、% Time in GC、Handles、Requests Queued；

事件查看器：IIS-W3SVC-WP/WAS 回收事件；

C:\dumps 目录容量与最近时间。

7.2 紧急止血 SOP

临时下调 privateMemory（例如 3.5GB→3.0GB）；

手动 OnDemand 回收（非高峰 appcmd recycle apppool /apppool.name:AppPool_ProdApi）；

确认 连接排水开启、预热任务生效；

开启/加强 ProcDump 条件抓取；

观察 30 分钟，评估是否需要短期启用 32 位以“快回收”。

7.3 回收策略模板（按业务量梯度）

8. 复盘：一次真实的“命中”

那次我们抓到的 Dump 报告里，XYZ.Pdf.Writer 出镜率极高，!dumpheap -stat 显示其相关对象持续累积，调用栈里是导出报表时反复 new 大对象但未 Dispose。开发同学一晚上把导出路径改成：

using 包裹所有 PdfDocument/Stream；

大数组复用 + 减少重复编码转换；

预压缩缓存对象设置上限 & 过期策略。

上线后三天观测：

9. 常见坑位与规避

• 只设时间回收，不设内存阈值：泄露加速时段会在两次时间点之间“爆雷”。
• 禁用交叠回收：极易在回收瞬间产生 502/504。
• InProc Session 在回收时丢失：生产环境务必迁移到 StateServer/SQLServer，或由网关保证粘性会话。
• ProcDump 未接受 EULA：首次加 -accepteula，否则不会生成 Dump。
• 仅看 GC，不看句柄：GDI/句柄泄露会完全绕过托管 GC。
• Dump 目录在系统盘：空间打满直接拖垮系统，建议独立盘/分区并定时清理。
• 32 位模式长期使用：吞吐/兼容性风险，作为过渡手段即可。
• 未开启回收事件日志：排查成本陡增，务必开启 logEventOnRecycle。

10. 一页式清单（可贴机柜门上的）

•  privateMemory / memory 已设且有依据
•  定时回收点分散、避峰，交叠回收为 **false? 不是！**应为 false（即允许交叠）
•  Orphan + ProcDump/Dump 目录健康
•  PerfMon 日志集：Private Bytes、Handles、% Time in GC、Requests Queued
•  预热策略生效（模块/脚本）
•  Session 非 InProc 或有粘性会话
•  事件日志能看到回收原因与时间线
•  代码层面对第三方库、COM、GDI 统一 Dispose/Release 规范

11.把战场留在夜里，把可复制留到白天

凌晨 4:05，最后一条曲线回落到 2.4GB。我在机房走了一圈，空调的风还像刚才那样冷，但心里暖了些。

第二天早会，我把这套参数、脚本、图表和踩坑写成了 Runbook。后来有人说：‘怎么感觉你们的 Windows 2008 比有些 2012/2016 还稳？’

我笑了笑——不是它稳，是我们把回收、预热、抓 Dump和编码规范都当成系统工程来做了。

如果你也在香港服务器上被 “w3wp 内存锯齿” 折腾，按上面的顺序落一遍：先止血，再找因，最后把经验固化。下次半夜来电，你大概率可以说：“给我 10 分钟”，然后继续喝咖啡