Windows Server内存泄漏的周期性检测与定时重启策略

Windows Server 出现内存泄漏最直观的表现是，服务器运行一段时间后响应变慢，远程桌面登录卡顿，甚至服务中断。查看任务管理器会发现可用内存持续减少，而某个进程（如 sqlservr.exe、w3wp.exe、lsass.exe 或自定义服务）的“专用工作集”无限制增长，即使业务低峰期也不释放。这通常不是物理内存不够，而是应用程序或驱动程序向系统申请了内存，使用完毕后没有正确归还，导致内存被“占着不用”。

解决这个问题不能只靠手工重启，必须建立一套“周期性检测与定时重启”的自动化机制。这套机制的核心逻辑是：设定内存使用阈值，编写检测脚本，通过任务计划程序定时触发，当检测到内存超过阈值时自动记录日志并优雅重启目标服务或整机。

在配置自动化之前，需要精准定位是哪个进程在泄漏内存。打开性能监视器（Perfmon），添加计数器“Process / Private Bytes”并选择你认为可疑的进程实例。持续观察24小时，如果某个进程的 Private Bytes 曲线只升不降，基本可以判定为泄漏源。更直接的方法是用 PowerShell 命令：

Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, @{Name="MemoryMB";Expression={[math]::Round($_.WorkingSet64/1MB,2)}}

这条命令列出当前占用物理内存最多的前10个进程。记录下泄漏进程的名称，比如 “MyLegacyApp”。接下来所有策略都围绕它展开。

阈值的设定要结合服务器总内存和业务容忍度。假设服务器有16GB内存，操作系统和其他必要服务需要保留4GB，那么给泄漏进程分配的上限可以设为8GB。当该进程专用工作集超过8GB时，就触发重启。下面是一个 PowerShell 检测脚本示例，保存为 Check-Memory.ps1：

$processName = "MyLegacyApp"
$thresholdMB = 8192
$logFile = "C:\Scripts\MemoryLog.txt"

$proc = Get-Process -Name $processName -ErrorAction SilentlyContinue
if ($proc) {
    $memMB = [math]::Round($proc.WorkingSet64 / 1MB, 2)
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $message = "$timestamp - ${processName} 内存使用: ${memMB}MB"

    if ($memMB -gt $thresholdMB) {
        $message += " [超过阈值 ${thresholdMB}MB，执行重启]"
        Add-Content -Path $logFile -Value $message

        # 重启服务（如果进程对应Windows服务）
        Restart-Service -Name "MyLegacyService" -Force

        # 如果是普通进程而非服务，用 Stop-Process 然后 Start-Process
        # Stop-Process -Name $processName -Force
        # Start-Process "C:\Path\MyLegacyApp.exe"
    }
    else {
        $message += " [正常]"
        Add-Content -Path $logFile -Value $message
    }
}
else {
    Add-Content -Path $logFile -Value "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') - 进程 ${processName} 未运行"
}

这个脚本逻辑很清晰：获取目标进程当前内存占用量，与阈值比较。如果超限，写入日志并重启对应服务；如果正常，只记录不动作；如果进程不存在，也记录一条信息。日志文件会持续累积，方便事后分析泄漏趋势。

脚本写好后，需要让它定时运行。打开“任务计划程序”，创建基本任务，触发器选择“每天”，然后勾选“重复任务间隔”设为30分钟或1小时，持续时间设为“无限期”。操作选择“启动程序”，程序填 “powershell.exe”，参数填：

-ExecutionPolicy Bypass -File "C:\Scripts\Check-Memory.ps1"

这里有几个关键细节：执行策略必须设为 Bypass，否则脚本可能因策略限制无法运行；务必勾选“不管用户是否登录都要运行”，并配置使用具有管理员权限的服务账号执行；在“条件”选项卡中取消勾选“只有在计算机使用交流电源时才启动”，这对虚拟机尤其重要。

检测间隔的选择取决于泄漏速度。如果进程在2小时内就能吃掉8GB内存，那么检测间隔必须缩短到30分钟以内，否则还没等脚本触发，服务器已经卡死。可以通过查看日志文件中内存增长速度来调整间隔，原则是“在内存耗尽前至少留出两次检测机会”。

仅靠阈值触发还不够。有些内存泄漏表现为缓慢增长，可能一周才达到阈值，但期间会产生内存碎片或句柄泄漏，导致性能逐步下降。因此需要增加一个定时重启策略，作为周期性“清理”。比如每周日凌晨3点强制重启目标服务。创建另一个任务计划，触发器设为“每周”，时间选业务低峰期，操作直接执行：

Restart-Service -Name "MyLegacyService" -Force

或者更彻底地重启整台服务器：

Restart-Computer -Force

定时重启和阈值触发双管齐下，能覆盖绝大多数泄漏场景。阈值触发应对突发性快速增长，定时重启解决慢性累积问题。两者结合后，服务器基本不会再因为内存泄漏而宕机。

在生产环境部署前，应该在测试环境验证这套机制的有效性。可以使用工具模拟内存泄漏，比如 Sysinternals 工具集中的 Testlimit 或自己写一个简单的泄漏程序。下面是一段用于测试的 PowerShell 代码，它会不断申请内存且不释放：

$leak = @()
while ($true) {
    $leak += New-Object byte[](100MB)
    Start-Sleep -Seconds 5
}

运行这段代码前确保测试机有足够内存，并且已经配置好检测脚本。观察任务计划是否按预期触发重启，日志是否完整记录。验证通过后再上线，避免因脚本错误导致生产服务异常中断。

自动化重启虽然解决了可用性问题，但如果每次重启都静默进行，运维团队可能完全不知道服务发生过中断，也无法追溯根因。因此检测脚本中应加入告警动作。可以在日志记录后增加发送邮件或调用 Webhook 的代码。例如使用 Send-MailMessage 发送邮件通知：

$smtp = "smtp.yourcompany.com"
$from = "server-alert@yourcompany.com"
$to = "ops-team@yourcompany.com"
$subject = "内存泄漏告警: $processName 已自动重启"
$body = "服务器 $env:COMPUTERNAME 上的进程 $processName 内存使用达到 ${memMB}MB，超过阈值 ${thresholdMB}MB，已执行自动重启。时间: $timestamp"
Send-MailMessage -SmtpServer $smtp -From $from -To $to -Subject $subject -Body $body

如果企业使用企业微信、钉钉或飞书机器人，也可以用 Invoke-RestMethod 发送消息到群聊。这样每次自动重启都会实时通知到运维人员，既能及时知晓，又为后续深入排查泄漏原因提供了时间点记录。

周期性检测与定时重启是治标的手段，最终还是要推动修复泄漏根源。常见的 Windows Server 内存泄漏原因包括：第三方驱动程序不释放非分页池内存（可通过 Poolmon 工具定位）；.NET 应用中事件处理器未取消订阅导致对象无法被GC回收；数据库连接或非托管资源未调用 Dispose；Windows 更新补丁本身的Bug等。在自动化策略稳定运行后，应收集日志中的内存增长曲线，结合性能监视器的“Process / Handle Count”和“Process / Thread Count”计数器，分析泄漏类型（是堆内存还是句柄泄漏），然后提交给开发或厂商修复。

如果泄漏源是 IIS 中运行的 Web 应用（w3wp.exe），处理方式更简单。IIS 本身提供了应用程序池的回收机制，无需额外脚本。打开 IIS 管理器，找到对应应用程序池，点击“高级设置”，在“回收”一栏中可以设置“特定时间间隔回收”（如每1440分钟）和“内存限制回收”（如私有内存超过8GB时回收）。勾选“发生回收时记录事件”，这样每次回收都会写入 Windows 事件日志，便于审计。IIS 的回收是优雅的，会先启动新工作进程处理新请求，旧进程完成现有请求后才退出，对用户几乎无感知。

如果不想写复杂脚本，也可以利用 Windows 内置的事件触发机制。打开“事件查看器”，在“Windows 日志 / 系统”中，可以附加任务到特定事件。例如当出现事件ID 2004（系统内存不足）时，自动触发重启脚本。方法是在该事件上右键选择“将任务附加到此事件”，后续配置与任务计划程序相同。这种方式更底层，能捕获到进程级检测覆盖不到的系统级内存耗尽场景，适合作为最后一道防线。

将上述脚本、任务计划配置、阈值设定依据、告警方式整理成标准化文档，纳入服务器上线检查清单。每台新部署的 Windows Server 都应评估是否可能存在内存泄漏风险，如果存在，直接套用这套模板进行配置。文档中应包含回滚方案：如果自动重启导致业务异常，如何快速禁用任务计划。只需在任务计划程序中右键禁用对应任务即可，恢复时间不超过10秒。

通过这套“检测脚本 + 阈值触发 + 定时重启 + 告警通知”的组合策略，Windows Server 内存泄漏问题可以从被动救火转变为主动防控。虽然不能根治代码层面的缺陷，但能保证业务连续性不受影响，为开发团队争取修复时间。实际运行中，这套机制稳定可靠，极少出现误判或漏判，是 Windows 运维中性价比最高的自动化手段之一。