IIS部署的ASP.NET Core 3.1生产环境安全捕获内存转储流程咨询

前置准备 #

操作前先完成以下检查，避免操作失败影响业务：

• 确认目标节点应用进程ID（PID）：可通过IIS管理器的工作进程视图查询，也可执行命令tasklist | findstr /i dotnet.exe（进程外托管）或tasklist | findstr /i w3wp.exe（进程内托管）确认，避免抓错进程
• 预留足够磁盘空间：内存转储文件大小与进程当前内存占用量基本一致，需保证目标存储磁盘剩余空间至少为进程内存占用的1.5倍
• 提前部署转储工具：优先使用微软官方的dotnet-dump全局工具或Procdump，无需重启应用即可完成捕获，避免额外影响

线上操作步骤 #

全程操作不影响其他集群节点业务运行：

1. 节点下线

• 将目标节点从负载均衡集群中下线，停止向该节点转发新请求
• 等待10~15分钟（可根据业务平均请求处理时长调整），让节点已接收的请求全部处理完成后再执行后续操作

因应用无会话状态，下线操作不会导致用户请求失败或数据丢失

2. 内存转储捕获

• 若使用dotnet-dump，执行命令：dotnet-dump collect -p <目标PID> -o <转储文件保存绝对路径>，等待命令执行完成即可，捕获过程中应用会短暂暂停，因节点已下线不会影响业务
• 若使用Procdump，执行命令：procdump -ma <目标PID> <转储文件保存绝对路径>，-ma参数指定捕获全内存转储，包含完整内存信息便于后续根因排查
  禁止在节点仍在线时执行捕获操作，避免应用暂停导致请求超时

转储后恢复操作 #

• 捕获完成后先校验转储文件是否存在、大小是否符合预期，确认无异常后可直接将节点重新接入负载均衡集群，也可先重启IIS站点/应用程序池释放内存后再上线
• 节点上线后观察1~2分钟，确认流量接入正常、请求响应无异常即可
• 如需多次捕获转储对比分析，重复上述流程即可，每次仅操作单个节点

注意事项 #

• 若需排查缓存占用过高问题，捕获转储前不要重启目标应用，避免缓存被清空丢失排查依据
• 若内存上涨速度极快，来不及等待存量请求处理完成，可在下线节点后立即执行捕获，不会影响线上业务
• 不要在业务高峰期同时下线多个节点执行操作，避免集群整体容量不足引发业务故障

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