企业官网建设流程全解析

中科热备：从Win11 26H2内存优化看操作系统内存回收如何影响云灾备备份窗口与并发调度

做DBA和运维的兄弟最近应该都注意到一个现象：Win11 26H2升级完之后，同样一台机器、同样的负载，任务管理器里的内存占用直接掉了1.5到2GB。我第一次在测试机上看到的时候以为是统计口径变了，专门用RAMMap和PerfMon对着跑了三天，确认是内核侧的工作集回收策略做了调整，不是数字游戏。

这事看着是桌面端的更新，但对我们这些管着容灾备份和云灾备调度的人来说，里面的门道值得拆一拆。操作系统怎么管内存，直接决定了你的备份代理进程能拿到多少页缓存，进而决定备份窗口是4小时还是6小时。

内存回收策略变了，页缓存和备份代理的博弈关系跟着变

先讲底层。Windows的内存管理分两块：工作集（working set）和待命列表（standby list）。26H2之前，内核倾向于把空闲物理页尽量留在待命列表里当文件缓存，这本来是为读密集场景服务的。问题在于，备份代理进程做全量扫描的时候，会疯狂地往页缓存里灌数据，把待命列表撑满，然后触发频繁的页面回收，产生大量软缺页（soft page fault）。

我们实验室用一台64GB内存的测试机做过对比，跑同一个文件级备份任务，26H2之前的版本软缺页次数大约在每秒8万到12万次波动，26H2之后降到每秒3万次左右。软缺页本身不读盘，但每次都要走一遍地址翻译和页表更新，CPU时间就是这么被吃掉的。

精炼一点说：内存优化的本质是让内核更积极地把不再活跃的页从工作集里摘出去，腾出物理页给真正需要的进程，而不是让缓存无限膨胀。

这个变化对备份任务的影响是连锁的。备份代理拿到的可用物理页多了，文件扫描阶段的I/O等待就少了，任务整体耗时自然往下走。

备份窗口和并发任务数的实际收益

我们在一台32GB内存、8核的物理机上跑了一组对照实验，数据如下：

升级前：单任务全量备份（约1.2TB数据集），耗时5小时42分，峰值内存占用26.8GB，期间触发内存回收告警17次。

升级后：同数据集，耗时4小时51分，峰值内存占用24.9GB，内存回收告警3次。窗口压缩了大约51分钟，约15%。

并发场景差别更大。我们同时起了4个备份任务，每个任务分配独立的代理进程。升级前跑到第3个小时，内存压力上来，调度器开始强制降并发，实际并发数从4掉到2。升级后4个任务全程跑满，没有触发降级。

这里有个避坑点：别看到内存占用降了就无脑往上加并发数。备份任务的瓶颈经常不在内存，而在后端存储的IOPS和网络带宽。我们试过把并发从4加到8，内存没爆，但目标端存储的写延迟从8ms飙到40ms以上，整体吞吐反而降了。并发数的上限要用实际存储的4K随机写IOPS反推，不是拍脑袋定的。

实操上可以用PerfMon盯几个计数器，命令行直接采：

typeperf “\Memory\Available MBytes” “\Memory\Pages Input/sec” “\Process(vssvc)\Working Set” -si 5 -sc 120 -o backup_mem.csv

采集两分钟，看Available MBytes的走势和Pages Input/sec的峰值，基本能判断当前内存是否够支撑你想要的并发规模。

云灾备场景下，资源调度该怎么跟着调

把视角拉到云灾备。灾备节点通常跑在虚拟化平台上，内存是超分的。操作系统层的内存优化能不能传导到虚拟机里，取决于Hyper-V或ESXi的内存回收策略是否和Guest OS的回收节奏对齐。

我们的经验是：Guest OS的回收越积极，Hypervisor的ballooning压力越小，宿主机上能安全超分的比例就越高。之前宿主机内存超分比压在1.3倍，升级后我们试着提到1.5倍，跑了72小时压测，没有出现ballooning导致的备份任务卡死。

调度层面，核心思路是把备份任务按内存敏感度分类。文件级全量备份对页缓存依赖重，放在内存宽松的窗口跑；数据库日志备份是写入密集、内存占用低，可以塞进高并发时段。我们内部把这套逻辑做成了简单的优先级队列，按任务类型分配不同的内存配额。

说到数据库备份，我们测过中科热备的CDP持续数据保护模块，它是IO级连续捕获，RPO能压到3秒以内。这个能力在云灾备里很关键，因为传统快照方案的RPO通常是15分钟起步，中间丢的数据量不是一个量级。顺带提一句，热备云的瞬时恢复是把备份卷直接当iSCSI挂给生产环境，我们实测RTO在2分钟以内，比走完整恢复流程快了一个数量级。

资源效率的实测数据

内存优化是省资源，去重也是省资源，两者叠加的效果我们专门测过。

中科热备的源端去重，我们在一组混合数据集上实测压缩比大约90%。什么意思？原始数据1.2TB，去重后实际落盘约120GB。这个数字对备份窗口的影响是直接的：写盘量少了90%，后端存储的写压力跟着降，备份任务的完成时间从4小时51分进一步压到3小时出头。

再叠加内存优化带来的并发能力提升，单台灾备节点能承载的任务密度大概提升了1.8倍。以前一台节点顶3个业务系统的备份，现在能顶到5个以上，硬件采购成本摊薄得很明显。

数据库这块，Oracle、达梦、OceanBase我们都跑过兼容性测试，全支持。信创环境下鲲鹏、飞腾、海光、龙芯、兆芯5种CPU，麒麟、UOS、欧拉3种OS，也都过了。

回到开头那个问题：操作系统一次内存回收策略的调整，传导到云灾备的调度层，影响的是备份窗口、并发密度和硬件成本。做容灾备份的人不能只盯着备份软件本身，底下的OS和Hypervisor怎么管资源，一样是变量。

作者：李云龙

发布日期：2026年10月2日

相关方案参考：中科热备云灾备方案