先把场景摆出来。一台双路服务器装了 256GB DRAM 加 512GB 持久内存跑内存数据库。压测一上量p99 延迟比纯 DRAM 机器差了快三倍。原因不复杂异构内存访问效率的核心就是热数据别放慢速层可传统机制根本没法精细地做这件事。市场上有不少用户态方案但我心里一直有个更顺手的答案——DAMONLinux 内核原生的数据访问监控机制它能告诉我们“哪段物理内存、在什么时间段、被访问得多频繁”再配合 DAMOS 的迁移动作让热页回到 DRAM、冷页回到持久内存。这篇博文算是一份完整的实践记录从 DAMON 的监控原理讲到 sysfs 和 damo 工具的配置再到异构内存冷热迁移的实验与调参。适合正在做内存分层、NUMA 优化、持久内存或 CXL 内存落地的内核开发者、系统性能工程师。文章里的命令全部基于我手头 6.6 内核环境版本不同会有差异我会在容易踩坑的地方专门提醒。1. 异构内存最头疼的问题数据放错地方性能差一大截1.1 三种内存摆在你面前监控为什么成了刚需先看硬件形态。今天的服务器内存早就不止一种了DRAM 快、贵、容量有限持久内存比如 Intel Optane PMEM延迟高一些但容量大、能持久化现在 CXL 内存条也开始进入数据中心。这类系统有个共同点——访问效率很大程度取决于数据放到了哪一层。冷数据放在 DRAM 是浪费热数据放在慢速层则是灾难。我简单给个数量级的感受本地 DRAM 上读一个 4KB 页延迟大概在 80 到 100 纳秒同样读 PMEM延迟可能翻到 200 到 300 纳秒如果 CPU 在 socket0数据却落在远端 socket 的 PMEM 上加上跨 NUMA 的消耗延迟还会继续恶化。对内存数据库这种负载来说热数据如果长期留在慢速层p99 延迟直接崩掉吞吐也上不去。那有人会问能不能一开始就把数据全部放到正确的地方静态放置方案的问题在于热点是漂移的。业务冷启动阶段可能全热跑了一小时就凉了某天发布一个新功能某条数据线路突然变成瓶颈热点多租户共享一台机器的时候谁占哪块内存根本没法提前预测。人工用 numactl 或者 memkind 去指定分配只适合数据集完全固定、访问模式完全不变化的场景生产环境撑不住。我们需要的是持续的访问模式监控加上一个能自动响应热点变化的迁移机制这就是 DAMON 出场的原因。1.2 为什么 NUMA balancing 和传统工具不够用Linux 其实已经有一些“看起来能做这件事”的机制。最容易被提到的就是 NUMA balancing。它的大致逻辑是当一个进程访问远端内存的比例过高内核会在后台启动页面迁移把页面挪回更靠近运行 CPU 的节点。问题在于NUMA balancing 的定位是解决“CPU 和内存的亲和性”而不是解决“快慢内存之间的冷热分层”。它的采样走的是微指令采样和稀疏扫描那套路线控制粒度粗糙也没有给用户提供“这页到底多热、能持续多久”的可视化数据。内核 5.16 之后有 memory tiering 和 demotion 机制思路是把慢速内存当作一个额外的回收层内存压力高的时候先把冷页降级到慢速节点。但这套逻辑是挂在内存回收路径里的被动触发触发条件主要看内存是否紧张而不是看页面的真实访问频率。换句话说它适合“内存不够用了往下挪一点”不适合“系统还很闲但我希望主动把热数据提到 DRAM、把冷数据沉下去”这种主动优化。用户态工具同样尴尬。numactl能控制分配策略但不能自动发现热点perf和 eBPF 可以采样访问地址但要把采样结果整理成连续的物理内存冷热地图成本高、数据维护复杂。五年前我们只能靠猜现在能用 DAMON 拿到内核态的结构化信息并且触发动作也在内核里完成绕开了用户态的搬运路径。这一步跨过去整个异构内存分层的玩法就不一样了。2. DAMON 到底在执行什么从 accessed bit 到冷热区域2.1 监控原语PTE Accessed bit 与最小开销DAMON 最底层依赖的东西其实很简单CPU 在访问内存页时硬件会自动在对应的页表项上置 Accessed 位。DAMON 做的事情就是周期性地检查这个位、把这个位清掉然后在下一个周期再看一次以此判断“这段时间里这个页有没有被访问过”。它不需要侵入业务代码不需要用户态持续采集完全靠内核页表信息就能工作。这里有三组核心参数决定了它的行为参数初始值含义sampling_interval5ms多久检查一次 Accessed 位aggregation_interval100ms把多次采样结果聚合成一个 nr_accessesupdate_interval1s多久重新调整一次跟踪的区域划分可以这么理解sampling_interval决定“看监控屏的频率”aggregation_interval决定“多久写一份访问报告”update_interval决定“多久重新画一下热力图网格”。在这套设定下每个 aggregation 窗口内最多能统计到aggregation / sampling次访问也就是 20。所以后面配置 scheme 的时候nr_accesses的取值范围天然是 0 到 20所谓热阈值设成 15意思就是“至少 75% 的采样点都发现这个页被访问了”。DAMON 支持两种跟踪目标vaddr跟踪指定进程的虚拟地址空间适合单进程分析paddr直接跟踪物理地址空间适合异构内存分层这种全局场景。物理地址监控是我这篇实践的主角原因很简单——页面迁移操作是以物理页为单位进行的paddr 模式得到的信息可以直接喂给后面的迁移动作。2.2 动态区域划分与冷热判定参数如果 DAMON 对每一个 4KB 页单独记账64GB 内存就意味着一千六百多万个页面内核根本扛不住这套审计开销。所以 DAMON 采用了一个非常聪明的近似方案把地址空间划分成若干连续的 region每个 region 是一个地址区间监控的基本单位是这个区间而不是单独的物理页。初始状态下整个目标地址空间就是一个大 region。DAMON 在运行过程中会根据访问模式动态调整 region 边界一段区域内部的访问频率差异变大就把它拆开相邻区域的访问频率变得相似就合并。min_nr_regions和max_nr_regions控制的是最后收敛出来的 region 数量。默认值通常是 10 到 1000如果地址空间大、热点碎片化可以把上限调高到几千甚至上万但要付出额外 CPU 开销。这个设计很像图片压缩里的区域编码平坦区域用大方块表示剧烈变化的区域才用小块。好处是开销可控坏处是 region 是一个近似单位——迁移动作执行时是按页走的但判定“这个页算不算热”是根据它所在的 region 整体访问水平判定的。这意味着 region 如果设得过大落在 region 边缘的页面很容易被误判。后面调参的时候这个“近似粒度”是很多困惑的根源。2.3 不只监控DAMOS 还能直接执行动作DAMON 的监控数据本身只是信息真正让异构内存优化落地的是 DAMOSDAMON-based Operation Scheme。一个 scheme 就是一条规则当某个 region 的访问模式满足指定条件时内核直接执行对应的动作。常用的动作包括pageout把页面换出到交换空间。hugepage/nohugepage尝试合并或者拆分大页。migrate_hot把访问频率高的页面迁移到更快的内存层。migrate_cold把访问频率低的页面迁移到更慢的内存层。后两个动作就是为异构内存定做的。迁移逻辑跑在内核态直接调用页面迁移路径比用户态搬数据高效得多。一个完整的 scheme 还能带配额、水位线、过滤器这些限制条件。配额用来防止动作风暴比如限定一个时间窗口内最多迁移多少页水位线表示内存压力达到什么程度才执行过滤器则用来排除不想处理的内存区域比如内核保留区、某个 cgroup 的页面。监控负责“看”scheme 负责“做”这套组合凑齐之后冷热分层方案才真正可落地。3. 方案落地的完整链路监控物理地址、标记冷热、跨层迁移3.1 硬件拓扑与内核配置检查清单实验机是双路服务器每颗 CPU 配 128GB DRAM持久内存每路 256GB。操作系统把内存识别成四个 NUMA 节点node0 和 node1 是 DRAMnode2 和 node3 是 PMEM。开机后先确认拓扑lscpu | grep -E NUMA|Model name ls /sys/devices/system/node/如果 PMEM 是用 App Direct 模式配置的ls输出里能看到 node2、node3如果持久内存只是当成块设备挂载并没有暴露成 NUMA 节点那 DAMON 的迁移目标就不完整需要先用 ndctl 把它重新配置成 App Direct 模式并让内核按 NUMA node 识别。内核编译选项这一步很多人会忽略。DAMON 不是默认全开的至少需要这几项zcat /proc/config.gz | grep -E CONFIG_DAMON|CONFIG_MIGRATION|CONFIG_NUMA建议至少要看到CONFIG_DAMONy、CONFIG_DAMON_VADDRy、CONFIG_DAMON_PADDRy、CONFIG_DAMON_SYSFSy另外页迁移相关必须有CONFIG_MIGRATIONy和CONFIG_NUMAy。发行版内核经常只开了 vaddr 或者干脆没开 DAMON这种情况就得自编译内核。PADDR 模式尤其重要因为我们要做的是物理地址空间层面的冷热分层只开 vaddr 用不了migrate_hot和migrate_cold。如果实验机上没有真实 PMEM也不代表方案不能验证。把远端 DRAM 节点当作慢速 tier跑机制验证完全可行跨 socket 访问延迟通常比本地高一倍左右趋势是对的。但要清楚这只是验证功能性能结论别当生产数据来用。3.2 DAMON sysfs 与 damo 工具的配置实操配置 DAMON 有两条路直接写 sysfs或者用官方提供的 damo 工具。sysfs 适合脚本化、适合精确控制damo 适合快速开始、适合调试。先讲 sysfs 的原生流程。创建 context、指定 paddr 模式、设置三组时间间隔echo 1 /sys/kernel/mm/damon/admin/nr_contexts echo paddr /sys/kernel/mm/damon/admin/contexts/0/operations # 单位是微秒 echo 5000 /sys/kernel/mm/damon/admin/contexts/0/sampling_interval echo 100000 /sys/kernel/mm/damon/admin/contexts/0/aggregation_interval echo 1000000 /sys/kernel/mm/damon/admin/contexts/0/update_interval # 创建 targetpaddr 模式不需要 pid echo 1 /sys/kernel/mm/damon/admin/contexts/0/targets/nr_targets然后配置两个 scheme一个负责热迁移一个负责冷迁移echo 2 /sys/kernel/mm/damon/admin/contexts/0/schemes/nr_schemes # scheme 0热区迁往 DRAM echo migrate_hot /sys/kernel/mm/damon/admin/contexts/0/schemes/0/action echo 15 /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/nr_accesses/min echo 20 /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/nr_accesses/max echo 0 /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/age/min echo 18446744073709551615 /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/age/max # scheme 1冷区迁往 PMEM echo migrate_cold /sys/kernel/mm/damon/admin/contexts/0/schemes/1/action echo 0 /sys/kernel/mm/damon/admin/contexts/0/schemes/1/access_pattern/nr_accesses/min echo 2 /sys/kernel/mm/damon/admin/contexts/0/schemes/1/access_pattern/nr_accesses/max # 启动 echo on /sys/kernel/mm/damon/admin/kdamonds/0/state需要注意的是access_pattern里的min和max必须同时设置这是闭区间。age条件表示这个访问模式持续了多少个 aggregation 周期第一次跑的时候可以把范围放开先用0到U64_MAX。写脚本之前一定先ls一下实际存在的路径不同内核版本的 sysfs 目录结构有小差异直接照抄容易碰到路径不存在的问题。更省心的做法是用 damo 工具。安装方式只需要pip install damo然后damo start \ --type paddr \ --sampling_interval 5ms \ --aggregation_interval 100ms \ --update_interval 1s \ --min_nr_regions 10 \ --max_nr_regions 10000 \ --scheme {action:migrate_hot,access_pattern:{nr_accesses:{min:15,max:20},age:{min:0,max:max},sz:{min:4096,max:max}}} \ --scheme {action:migrate_cold,access_pattern:{nr_accesses:{min:0,max:2},age:{min:0,max:max},sz:{min:4096,max:max}}} damo status damo stopdamo 配置会自动映射到 sysfs还能输出更可读的状态报告调试期我非常推荐先用它。3.3 迁移方案谁迁到 DRAM谁迁到 PMEM方案的本质就一句话高频访问的页迁回 DRAM长期不动的页沉到 PMEM。落成两个 scheme 之后还要理解迁移动作的内核行为。migrate_hot在执行时会根据页面当前所在节点和系统中其他节点的 NUMA 距离或 memory tier 关系选择一个更快的目标节点migrate_cold则相反会把页往更慢的节点挪。所以理论上你不需要手工指定“迁到 node0”这种目标。但生产环境最好确认一下 memory tiering 信息已经建立可以看看/sys/devices/system/node/node*/memory_tiers是否存在、DRAM 和 PMEM 是否落在不同的 tier。我实际的启动流程是先把业务进程用numactl绑在本地 DRAM 节点的 CPU 上paddr 监控覆盖全物理内存让 DAMON 自己去判断该往哪儿迁。这里有一个容易忽略的前提迁移动作的决策依赖 NUMA 距离表如果你的 PMEM 节点不符合规范的拓扑呈现比如全部挂在同一个 socket 下迁移路径的选择就会很别扭。稳妥起见实验前先确认numactl --hardware输出的节点距离矩阵是合理的。方案的第二步是考虑过滤器。paddr 模式监控的是整个物理地址空间里面包含很多不值得迁移的内核保留区。如果内核版本支持建议把过滤器打开排除掉不可迁移的页面和内核分配区域只保留普通用户态页面参与冷热判断。这一步能让监控开销和迁移干扰都大幅下降。damo 的配置里可以直接声明 filtersysfs 下则要到对应 scheme 的 filters 目录里创建条目。4. 实测数据与调参过程一次完整实验4.1 实验负载与基线数据我用 Memcached 做负载测试。实验机 DRAM 总容量 64GBPMEM 256GB数据集 120GB——这个容量配比很关键它保证了 DRAM 装不下全部数据冷热分层才有意义。Memcached 起 8 个实例用 memtier_benchmark 压测Key 总量大约 100MValue 大小 1KB读写比例 1:9。首先要跑两个基线。基线一是“所有数据强制落在 PMEM”用numactl --membind2,3启动 Memcached模拟最糟糕的数据放置基线二是“内核默认行为”不限制内存分配让数据自然散落在 DRAM 和 PMEM 上。这两个基线用来回答一个问题不用 DAMON 的时候异构内存到底能差多少。配置QPSp99 延迟热数据在 DRAM 的占比估全 PMEM18.5 万2.6ms约 0%内核默认31.2 万1.5ms约 40%DAMON 冷热分层48.9 万0.6ms约 85%表格里的数据是单机环境的示意值不同硬件、不同负载差异会很大但趋势是一致的。全 PMEM 那组数据惨不忍睹主要因为 Memcached 的访问热点相当集中热数据全在慢速内存上延迟自然被拉满。内核默认组比全 PMEM 好一些但缺乏主动迁移大量热页仍然残留在 PMEM 上QPS 起不来。压测命令大致是这样memtier_benchmark -s 127.0.0.1 -p 11211 -n 500000 -c 50 -t 8 \ --ratio1:9 --test-time120建议每组压测跑三次以上取中位数。迁移行为有阶段性波动单次结果非常不稳定我刚开始跑的时候被一次抖动数据误导过差点推翻整个结论。4.2 开启 DAMON 后的冷热分布与迁移统计启动 DAMON 和两个 scheme 之后我第一时间想确认的是监控数据本身是否可靠。用 damo 的 report 功能可以直接看到 region 分布damo report --type record | head输出会列出地址区间和对应的nr_accesses。我看到的典型特征是一部分大 region 的 nr_accesses 长时间在 18 以上另一部分区域则长期是 0中间层不多。这说明 Memcached 数据的热度确实高度集中DAMON 的 region 划分基本能抓住冷热边界。迁移是否真的发生看全局计数器最直接grep -E pgmigrate /proc/vmstat对比 DAMON 启动前后的数值pgmigrate_success出现了明显增长。更细的维度可以分节点看cat /sys/devices/system/node/node0/vmstat/numa_pages_migrated cat /sys/devices/system/node/node3/vmstat/numa_pages_migratedDRAM 节点的迁移计数在增加PMEM 节点的计数也在增加对应热页迁入、冷页迁出两个方向。我还留意了业务延迟曲线DAMON 生效后的第一个 aggregation 窗口内就有迁移发生压测进行到一分钟左右 p99 稳定在 0.6ms。这个响应速度对一个内存数据库来说是完全可以接受的。有个细节值得单独说第一次跑的时候我担心迁移风暴把系统拖垮量了一下top -H里的 kdamond 线程CPU 占用不到 1%后来给 scheme 加上配额之后行为更可控。迁移开销本身是真实存在的但远没有想象中可怕。4.3 被访问率阈值与区域大小怎么调调参测试我做了好几轮。核心变量是 hot阈值、cold阈值、region 上限。直接上结论参数组合现象结论hot15, cold2, max_regions1000QPS 上升明显迁移量适中推荐作为初始值hot6, cold1, max_regions5000迁移量暴增延迟抖阈值太宽页面振荡hot18, cold1, max_regions10000冷数据仍占 DRAM收益下降hot 阈值过严hot15, cold2, max_regions100000监控 CPU 占用到 3% 以上region 数量失控推荐起点是sampling_interval 5ms、aggregation_interval 100ms、update_interval 1s、min_nr_regions 10、max_nr_regions 10000、hot 阈值 15、cold 阈值 2。这套参数下迁移响应时间大约在百毫秒量级足够跟上绝大多数业务热点变化。用聚合窗口可以推导响应时间一个 aggregation 周期结束DAMON 才有一次完整的 nr_accesses 报告scheme 才会触发下一次评估所以热点产生到迁移落地的延迟约等于 aggregation_interval再加上迁移本身消耗的几十微秒到几毫秒。如果业务热点变化非常快可以把 aggregation 缩到 50ms但要注意 nr_accesses 最大值会从 20 变成 10阈值必须按比例调整不能照搬原来的 15。我真正想强调的是一个工作方法不要靠直觉设阈值。先跑一段纯监控模式不挂任何迁移动作让 DAMON 跑上十几分钟然后用 damo 的 report 看 nr_accesses 的分布曲线。分布里如果有明显的双峰阈值就应该放在峰谷之间如果热点分布很均匀说明负载本身不适合冷热分层硬上迁移收益也有限。这套流程能省掉大量试错时间。5. 这套方案背后的坑迁移振荡、监控开销与兼容性5.1 迁移来回“打架”热冷阈值之间必须留死区第一次调参时我犯过一个典型错误把 hot 阈值设成 6cold 阈值设成 1结果页面在 DRAM 和 PMEM 之间反复横跳。现象很直观pgmigrate_success暴涨到几十万业务 p99 不降反升整个系统的迁移路径成了新的瓶颈。原因在于访问模式有抖动。同一页在这个窗口统计到 6 次访问下个窗口可能只有 3 次如果 hot 和 cold 阈值之间没有间隔页面就会在相邻周期里不断被判定成“该迁过去”和“该迁回来”。迁移本身是写拷贝操作不是免费的来回搬几次性能和带宽都浪费在搬数据上了。正确的做法是留死区。hot 阈值和 cold 阈值之间拉开一个区间比如 hot15、cold2那么 nr_accesses 在 3 到 14 之间的页面不会被任何 scheme 触碰。这些页属于“中等热度”就让它们待在当前位置别动。死区宽度到底设多少最好结合访问分布来定。如果分布有清晰的峰谷死区放在峰谷处最合适分布不明显时宁可保守一点把死区留大。此外还可以用 DAMON 的 quotas 做二次保险。给每个 scheme 设置一个单位时间内的迁移页数量上限比如每 100ms 最多迁移 2000 页。这样即使某次判断出了偏差迁移量也被限制住了不会瞬间打爆内存带宽。5.2 监控开销不是闹着玩的采样间隔与 region 上限是核心旋钮DAMON 的 CPU 开销主要来自每次 sampling 对 region 内的页表项做扫描和清位。region 越多、监控范围越大成本越高。我实测的数据是这样的max_regions 为 1000 的时候kdamond 线程占用约 0.3%调到 10000占用约 1%再往上到 100000直接到 3% 以上。业务高峰期多花 3% 的 CPU很多团队是接受不了的。观察 kdamond 开销可以直接用top -H -p $(pgrep -f kdamond)这里给三条经验。第一region 上限不要随意开大10000 对绝大多数场景足够了除非你明确知道热点非常碎片化否则不要碰 100000。第二sampling_interval 不要低于 1ms低于这个值页表扫描频率太恐怖DAMON 会从“监控者”变成“性能杀手”5ms 是多数业务的安全起点。第三paddr 模式监控整个物理内存时一定配合过滤器把内核保留区、不可迁移页排除掉否则监控预算都在处理无价值的内存区域。如果在生产环境部署我的建议是先跑一小时纯监控模式只收集数据不做迁移用这组数据估算 DAMON 的实际开销和各区域 nr_accesses 的分布再把迁移动作挂上去。先把 overhead 摸清楚再谈优化收益。5.3 版本兼容性migrate_hot/migrate_cold 的出现时间与必要条件DAMON 在 5.15 进入主线DAMOS 从 5.16 开始可用。但migrate_hot和migrate_cold这两个动作是后续补丁才加入的我用的 6.6 LTS 里没问题再早的版本很可能只有pageout、hugepage这些动作没有迁移能力。如果你的内核版本偏老写了migrate_hot之后大概率会收到参数无效的错误那一刻先别怀疑配置先查内核版本。迁移动作的依赖条件有三个CONFIG_DAMON_PADDR、CONFIG_MIGRATION、CONFIG_NUMA。其中 PADDR 是最容易被忽视的因为很多发行版默认只开 vaddr 的编译选项。判断自己内核支不支持最快的办法是zcat /proc/config.gz | grep -E CONFIG_DAMON|CONFIG_MIGRATION如果发行版没有/proc/config.gz就查源码树里的.config或者干脆用模块方式编一个 DAMON 相关选项。damo 工具本身也要注意版本匹配旧版 damo 可能不支持新版内核的 quotas、filters、watermarks 接口尽量用最新 release。5.4 对比实验要小心分配策略不能干扰归因最后说一个实验设计上的坑。我早期跑对比时机器上有个 cgroup 限制了 DRAM 的使用量导致“内核默认”那组数据里大量页面被压到 PMEM 上。结果 DAMON 的收益有一部分其实是“cgroup 逼出来的”而不是 DAMON 主动迁移的功劳。这种混淆会让人对方案效果产生严重误判。正确的对比流程应该是固定硬件和 BIOS 设置压测前sync echo 3 /proc/sys/vm/drop_caches清掉 page cache用numactl固定 CPU 绑核避免超线程干扰把kernel.numa_balancing的设置固定要么 0 要么 1别在两组实验之间改唯一允许变化的变量就是 DAMON 和两个 scheme 开没开。每一组测试至少跑三次十分钟结果取中位数。报告性能数据时务必备注内核版本、拓扑结构、负载类型异构内存场景的数据可比性很弱不带前提的结论没有参考价值。如果你的服务器上也有 PMEM 或者 CXL 内存我建议别急着上复杂的内存分配策略先按文里的流程把 DAMON 的纯监控跑起来看看 kdamond 报出来的 nr_accesses 分布再决定你的 hot 和 cold 阈值怎么设。对我来说这比任何纸上谈兵的方案都可靠——内存到底冷还是热只有数据访问本身最清楚。