企业官网建设流程全解析

1. 从一次内存抖动排查说起：DAMON到底解决了什么问题

前段时间帮一个朋友看他们线上服务的问题，现象很典型：一台跑了容器化业务的机器，内存看着没满，但业务侧偶发延迟毛刺，P99时不时飙一下。用常规的free、vmstat看，指标都挺正常，si/so也不高，但就是有抖动。后来用perf抓了一下，发现大量时间耗在kswapd和直接回收路径上，也就是说，内存其实一直在被回收，只是没触发到明显的swap换入换出而已。

这个场景其实非常常见。传统的内存监控手段，不管是/proc/meminfo还是vmstat，给的都是全局聚合的视角——整机还剩多少内存、回收了多少页。但你真正想知道的是：到底是哪个进程、哪段地址范围在被频繁访问，导致这块内存一直被判定为"热"而无法回收？这个问题在聚合视角下是回答不了的。

DAMON（Data Access MONitor）就是冲着这个痛点来的。它是Linux内核里一个轻量级的数据访问监控框架，核心能力是：让你指定一段虚拟地址范围（可以是某个进程的，也可以是物理地址空间），然后它用极低的开销去采样这段范围的访问情况，最后告诉你"这段内存里哪些区域是热的、哪些是冷的"。有了这个信息，你就能做很多事情：精准回收冷内存、做分层内存管理、给业务做内存画像、甚至驱动一些自动化的内存优化策略。

这篇文章我打算把DAMON从原理到实操完整拆一遍。适合谁看？如果你在做内核性能优化、内存管理、容器资源调度，或者单纯对内核子系统感兴趣想动手跑一跑，那这篇应该能帮到你。我会尽量把"为什么这么设计"讲清楚，而不是只丢一堆API和参数。毕竟DAMON这东西，光看文档你会觉得挺简单，真上手调的时候坑不少。

2. DAMON的整体设计与核心思路拆解

2.1 为什么不用传统的页表扫描方案

要理解DAMON的设计，得先知道它不做什么。内核里其实早就有访问监控的机制，比如通过页表的Accessed位（PTE young bit）来判断一个页最近有没有被访问。你完全可以写个模块，定期遍历页表，把Accessed位读出来再清掉，这样就能统计访问频率。

但这个方案有几个致命问题。第一，遍历页表本身开销巨大。一个进程的页表可能几十万上百万个PTE，你每次扫描都要走一遍，这在生产环境根本扛不住。第二，Accessed位是二值的，只能告诉你"这段时间内访问过没有"，没法量化访问的密集程度。第三，精度和开销难以平衡，你想精度高就得扫得勤，扫得勤开销就爆炸。

DAMON换了个思路：基于采样的区域级监控。它不逐页看，而是把目标地址范围切成若干区域（region），然后随机挑一些位置去采样，通过统计采样命中情况来推断每个区域的访问热度。这个思路的关键在于——用统计近似代替精确扫描，牺牲一点点精度，换来数量级上的开销下降。

提示：DAMON的采样是"随机位置采样"，不是"随机区域采样"。它会在整个目标范围内随机撒点，然后看这个点落在哪个区域，从而给对应区域累加计数。这个设计细节后面讲原理时会再展开。

2.2 三个核心抽象：Target、Region、Scheme

DAMON的整个模型可以浓缩成三个概念，理解了这三个，基本就理解了一半。

Target（监控目标）：就是你要监控的那段地址空间。它可以是某个进程的虚拟地址空间（pid指定），也可以是物理地址空间（paddr指定）。一个DAMON实例可以挂多个target。

Region（区域）：Target被切分成若干个region，每个region是一段连续的地址范围，带有一个访问频率的统计值。DAMON会动态调整region的划分——访问模式变化剧烈的地方切细一点，平稳的地方合并粗一点。这个动态调整机制叫自适应区域调整（adaptive regions adjustment），是DAMON能兼顾精度和开销的核心。

Scheme（方案）：这是DAMON的"动作"部分。你定义一组规则，比如"如果某个region的访问频率低于阈值，就把它标记为冷内存"，然后DAMON在每轮监控结束后，对满足条件的region执行你指定的动作。动作可以是stat（只统计）、pageout（换出）、cold（标记为冷）、madvise等。

这三者的关系是：Target提供监控对象，Region承载监控结果，Scheme决定后续动作。整个DAMON就是围绕这三者循环运转的。

2.3 采样机制与开销控制

DAMON的采样逻辑，我尽量用大白话讲清楚。假设你的target是1GB的地址范围，DAMON把它切成N个region。每一轮采样，它会：

1. 在1GB范围内随机选一个地址；
2. 找到这个地址属于哪个region；
3. 检查这个地址对应的页最近有没有被访问（通过页表的Accessed位）；
4. 如果访问了，给这个region的计数加一。

重复这个过程sample_count次（比如5000次），一轮就结束了。然后DAMON根据每个region的命中比例，估算出它的访问频率。

这里有个很妙的点：采样次数是固定的，跟target大小无关。你监控1GB和监控100GB，每轮的采样开销是一样的。这就是DAMON能扩展到很大地址范围的原因。当然，target越大，每个region分到的采样点越少，统计噪声就越大，所以region的粒度需要相应调整。

开销控制上，DAMON还做了几件事。一是采样间隔可调（sample_interval），默认5ms，你可以拉长来降开销。二是聚合间隔可调（aggr_interval），默认100ms，控制多久汇总一次结果。三是最小region数（min_nr_regions）和最大region数（max_nr_regions）的约束，防止region数量失控导致管理开销上升。

2.4 自适应区域调整：DAMON的精髓所在

这是我觉得DAMON设计里最值得琢磨的部分。固定切分region的问题是：你不知道该切多细。切太细，region数量爆炸，管理开销大；切太粗，热点区域和冷区域混在一起，统计结果没意义。

DAMON的做法是动态调整。每轮聚合后，它会看相邻region的访问频率差异。如果两个相邻region的频率差很大，说明这里有个"边界"，需要切开；如果频率差不多，说明它们本质是一类，可以合并。通过这种"分裂-合并"的迭代，region的划分会逐渐收敛到跟实际访问模式匹配的状态。

具体算法上，DAMON用的是类似加权直方图的思路。它维护每个region的访问计数，然后根据计数的分布来决定分裂和合并。分裂时会在频率变化最大的地方切一刀，合并时会把频率相近的相邻region并起来。整个过程是自动的，你只需要给个region数量的上下界就行。

注意：自适应调整需要几轮才能收敛，所以DAMON刚启动时统计结果可能不太准。如果你要做精确分析，建议让它跑一段时间（比如几十个聚合周期）再看数据。

3. 核心细节解析与实操要点

3.1 内核配置：编译选项怎么选

要用DAMON，首先内核得编进去。相关的配置项有这么几个：

CONFIG_DAMON=y CONFIG_DAMON_VADDR=y CONFIG_DAMON_PADDR=y CONFIG_DAMON_SYSFS=y CONFIG_DAMON_DBGFS=y

逐个说下。CONFIG_DAMON是核心框架，必须开。CONFIG_DAMON_VADDR提供虚拟地址监控能力，CONFIG_DAMON_PADDR提供物理地址监控能力，这两个按需开——如果你只监控进程地址空间，PADDR可以不开。CONFIG_DAMON_SYSFS和CONFIG_DAMON_DBGFS是两套用户态接口，SYSFS是较新的、推荐的接口，DBGFS是老的调试接口，功能更全但不够稳定。

我的建议是两个接口都开。SYSFS适合做生产环境的稳定控制，DBGFS适合做实验和调试，因为它的功能更细，能看到更多中间状态。实测下来，DBGFS的schemes目录能直接看到每个region的统计，调参的时候非常方便。

编译的时候有个坑：DAMON依赖CONFIG_MMU，在没有MMU的平台上编不了。另外如果你用的是较老的内核（5.15之前），DAMON的接口和现在差别挺大，建议至少用6.1以上的版本，接口稳定，功能也全。

3.2 用户态接口：SYSFS与DBGFS的区别

两套接口的定位不太一样，我列个表对比一下：

SYSFS接口的目录结构是分层的：kdamonds/下面可以有多个kdamond实例，每个实例下面有contexts/，每个context下面有targets/和schemes/。这个层级关系要理清楚，不然配置的时候容易搞混。

DBGFS就直白多了，直接是<pid>/这样的目录，进去就是schemes、monitoring_attrs这些文件。调参的时候我一般用DBGFS，因为改完立刻能看到效果，不用像SYSFS那样一层层cd进去。

提示：DBGFS需要内核开CONFIG_DEBUG_FS，并且debugfs要挂载。有些发行版默认不挂debugfs，记得先mount -t debugfs none /sys/kernel/debug。

3.3 关键参数逐个拆解

DAMON的参数不少，但真正影响行为的就那么几个。我把最关键的挑出来讲。

sampling interval（采样间隔）：两次采样之间的时间。默认5ms。这个值越小，采样越密，统计越准，但开销越大。实测在普通x86机器上，5ms间隔、5000次采样的开销大概在1% CPU以内，可以接受。如果你监控的地址范围特别大，可以适当拉长到10ms甚至20ms。

aggregation interval（聚合间隔）：多久把采样结果汇总一次，并触发scheme执行。默认100ms。这个值决定了你响应访问模式变化的速度。设太小，scheme频繁触发，开销上升；设太大，响应迟钝。一般保持默认就行，除非你有特殊的实时性要求。

sampling count（采样次数）：每轮采样的次数。默认根据region数量自动算，一般是region数的几倍。这个值直接影响统计精度。有个经验公式：采样次数至少要是region数的10倍以上，统计结果才比较可信。比如你有100个region，采样次数最好在1000以上。

region数量上下界：min_nr_regions默认10，max_nr_regions默认1000。这两个值约束了自适应调整的范围。如果你监控的地址范围访问模式很复杂，可以把max调大，但注意region越多，每轮的管理开销越大。

scheme的access pattern：这是scheme的核心，定义了"什么样的region算命中"。它有三个维度：sz（大小范围）、nr_accesses（访问次数范围）、age（年龄范围）。比如你可以定义"大小在4KB到1MB之间、访问次数小于10、年龄大于5个聚合周期"的region为冷内存。这三个条件是与的关系，都满足才触发。

3.4 监控目标的指定方式

指定target有几种方式，各有适用场景。

按pid监控：最常用。echo <pid> > <target>/pid就行。DAMON会监控这个进程的整个虚拟地址空间。注意，进程退出后target会失效，需要重新配置。

按物理地址监控：echo <start> <end> > <target>/paddr。适合监控特定物理内存区域，比如某个设备的内存、或者你想做整机物理内存画像的时候。

按虚拟地址范围监控：这个稍微绕一点，需要先指定pid，再通过init_regions指定具体的地址范围。DBGFS下是往<pid>/init_regions写<start> <end> <weight>的格式。weight是初始权重，影响自适应调整的初始划分。

我个人的经验是，做进程级内存分析用pid就够了，DAMON会自动覆盖整个地址空间。只有当你明确知道要监控某段特定地址（比如某个mmap出来的大块内存）时，才需要手动指定范围。

4. 实操过程与核心环节实现

4.1 环境准备与内核编译

先确认你的内核版本。uname -r看一下，建议6.1以上。然后检查DAMON是否已经编进去了：

ls /sys/kernel/mm/damon/admin/ 2>/dev/null && echo "SYSFS OK" ls /sys/kernel/debug/damon/ 2>/dev/null && echo "DBGFS OK"

如果目录不存在，说明内核没开DAMON，需要重新编译。编译流程不复杂，但有几个点要注意。

下载内核源码后，make menuconfig，在Memory Management options下面找到DAMON相关的项。或者直接改.config：

CONFIG_DAMON=y CONFIG_DAMON_VADDR=y CONFIG_DAMON_PADDR=y CONFIG_DAMON_SYSFS=y CONFIG_DAMON_DBGFS=y CONFIG_DEBUG_FS=y

然后make -j$(nproc)编译，make modules_install && make install安装，重启选新内核。

注意：如果你是在虚拟机里做实验，编译内核前先确认磁盘空间够。完整编译一次内核大概需要20-30GB空间，别编到一半空间不够了。

4.2 用DBGFS跑第一个监控实例

DBGFS上手最快，我们先用它跑一个最简单的例子。假设要监控pid为1234的进程。

# 挂载debugfs（如果没挂的话） mount -t debugfs none /sys/kernel/debug # 进入DAMON目录 cd /sys/kernel/debug/damon # 创建监控目标 mkdir 1234 # 设置监控属性 echo 5000 > 1234/monitoring_attrs/sample_count echo 5000 > 1234/monitoring_attrs/sample_interval echo 100000 > 1234/monitoring_attrs/aggr_interval echo 10 > 1234/monitoring_attrs/min_nr_regions echo 1000 > 1234/monitoring_attrs/max_nr_regions # 启动监控 echo on > monitor_on

启动后，1234/目录下会出现schemes、regions等文件。regions文件里就是当前的region划分和统计结果，格式是<start> <end> <nr_accesses> <age>。你可以cat出来看看。

这里有个细节：sample_interval和aggr_interval的单位是微秒，不是毫秒。我一开始按毫秒填，结果采样间隔变成了5秒，统计完全不准。这个坑踩过一次就记住了。

4.3 配置一个冷内存识别scheme

光监控不够，我们配个scheme，让它自动识别冷内存。在1234/schemes/下创建一个scheme：

mkdir 1234/schemes/s cd 1234/schemes/s # 设置访问模式：访问次数小于10，年龄大于3 echo "0 0 10 3" > access_pattern/sz/nr_accesses/age # 设置动作：标记为冷内存 echo cold > action # 设置应用范围：所有region echo 0 > target_nid

等等，这里的access_pattern格式我得说清楚。DBGFS下，access pattern是三个文件：sz、nr_accesses、age，每个文件里写min max。所以正确的写法是：

echo "0 0" > access_pattern/sz echo "0 10" > access_pattern/nr_accesses echo "3 0" > access_pattern/age

age的max写0表示无上限。这样配置的意思是：大小不限、访问次数在0到10之间、年龄大于3的region，执行cold动作。

cold动作本身不做什么实际的事，它只是把region标记出来，你可以通过regions文件看到哪些被标记了。如果你想真的回收内存，可以用pageout动作，但那需要配合其他机制，风险也更高，建议先在测试环境验证。

4.4 用SYSFS做生产级配置

DBGFS适合实验，生产环境建议用SYSFS。SYSFS的配置流程稍微繁琐一点，因为层级多。

cd /sys/kernel/mm/damon/admin # 创建kdamond实例 echo 1 > kdamonds/nr_kdamonds # 配置第一个kdamond cd kdamonds/0 echo 1 > contexts/nr_contexts # 配置context cd contexts/0 echo 1 > targets/nr_targets echo 1 > schemes/nr_schemes # 配置target cd targets/0 echo 1234 > pid # 配置scheme cd ../../schemes/0 echo 0 > access_pattern/sz/min echo 0 > access_pattern/sz/max echo 0 > access_pattern/nr_accesses/min echo 10 > access_pattern/nr_accesses/max echo 3 > access_pattern/age/min echo 0 > access_pattern/age/max echo cold > action # 启动 cd /sys/kernel/mm/damon/admin/kdamonds/0 echo on > state

SYSFS的路径比较深，建议写个脚本封装一下。我自己的做法是写个bash函数，把常用的配置参数化，这样切换监控目标的时候不用每次敲一长串路径。

4.5 读取和分析监控结果

监控跑起来后，怎么读结果？DBGFS下直接cat <pid>/regions，输出格式是每行一个region：

0 4096 15 2 4096 8192 3 5 8192 16384 0 8 ...

四列分别是：起始地址、结束地址、访问次数、年龄。访问次数越高说明越热，年龄越大说明越久没被访问（年龄的定义是"连续多少个聚合周期访问次数没超过阈值"）。

SYSFS下读取稍微麻烦点，需要先触发一次update_schemes_stats，然后从schemes/0/stats里读。不过SYSFS的统计粒度比较粗，只有总的命中次数，看不到每个region的细节。所以做详细分析还是得用DBGFS。

分析的时候我一般关注两个指标：热区占比和冷区年龄分布。热区占比高说明内存压力大，冷区年龄分布能告诉你哪些内存是真的可以回收的。如果大量region的年龄都很高但访问次数不为零，说明这些内存是"偶尔被碰一下"的类型，回收要谨慎。

5. 常见问题与排查技巧实录

5.1 监控启动失败排查表

DAMON启动失败的原因挺多，我整理了个速查表：

5.2 统计结果不准怎么办

统计不准是最常见的问题，原因通常有几个。

采样次数不够。前面说过，采样次数至少要是region数的10倍。如果你有500个region但只采样1000次，那每个region平均才2个采样点，统计噪声巨大。解决办法是调大sample_count，或者调小max_nr_regions。

聚合间隔太短。聚合间隔太短的话，每轮采样的样本还没积累够就汇总了，结果波动大。建议aggr_interval至少是sample_interval的20倍以上。

自适应调整没收敛。DAMON刚启动时region划分是初始值，需要几轮调整才能匹配实际访问模式。如果你在启动后立刻读结果，看到的可能是还没收敛的中间状态。建议至少等10个聚合周期。

提示：判断是否收敛，可以连续读几次regions，看region的边界是否稳定。如果边界一直在变，说明还在调整中。

5.3 开销控制的实战经验

DAMON号称低开销，但配置不当照样能把CPU吃满。我实测过几组配置，分享下经验。

在4核8G的虚拟机上，监控一个约2GB地址空间的进程：

结论是：sample_count和sample_interval是开销的主要来源。生产环境建议用5000次采样、5ms间隔这个组合，开销和精度比较平衡。如果只是做粗略画像，1000次采样也够用。

还有个隐藏开销来源是region数量。region越多，每轮聚合时的排序、分裂、合并操作越耗时。我见过有人把max_nr_regions设成10000，结果聚合阶段CPU直接飙到20%。一般1000以内是安全的。

5.4 几个容易踩的坑

坑一：pid复用。Linux的pid是会复用的。你监控pid 1234，进程退出后pid 1234可能被新进程占用，DAMON会继续监控这个新进程，但你以为还在监控老进程。解决办法是监控的时候记录进程的启动时间，或者用cgroup路径而不是pid来指定target（较新内核支持）。

坑二：地址空间变化。进程运行过程中会mmap/munmap，地址空间是动态变化的。DAMON的region划分是基于监控开始时的快照，如果地址空间变化剧烈，统计结果会失真。对于这种场景，建议缩短聚合间隔，让DAMON更快地重新调整。

坑三：DBGFS的写入顺序。DBGFS下配置scheme时，必须先写access_pattern再写action，顺序反了会报错。这个在文档里没明说，我是试出来的。

坑四：多实例的资源竞争。同时跑多个kdamond实例会争抢CPU和内存带宽。如果非要跑多个，建议错开它们的采样时间，或者降低各自的采样频率。

5.5 和其他工具的配合使用

DAMON不是孤立的，它跟其他工具配合能发挥更大价值。

跟perf配合：DAMON告诉你"哪段内存热"，perf告诉你"为什么热"。先用DAMON定位热点区域，再用perf record针对性地采样，效率高很多。

跟cgroup配合：DAMON可以按cgroup监控（需要内核支持），这样你能做容器级的内存画像。对于多租户环境，这个能力很实用。

跟numa配合：DAMON的region统计可以指导NUMA迁移决策。热region往近端节点迁，冷region往远端节点迁，能显著降低内存访问延迟。不过这个需要你自己写迁移逻辑，DAMON只提供数据。

6. 进阶玩法与扩展思路

6.1 基于DAMON的自动化内存回收

DAMON最实用的进阶玩法是驱动自动化内存回收。思路是：配一个pageoutscheme，让DAMON自动把冷内存换出。这样比内核默认的LRU回收更精准，因为它基于实际的访问频率而不是粗略的LRU链表。

配置上，把action从cold改成pageout，然后调整access pattern的阈值。阈值怎么定？我的经验是先用cold模式跑一段时间，观察冷region的访问次数分布，然后取一个略高于分布峰值的值作为阈值。比如大部分冷region的访问次数在5以下，那阈值就设10，留点余量。

注意：pageout动作会真的触发内存换出，在SSD上还好，在机械盘上可能引起IO抖动。生产环境用之前一定要在测试环境验证，并且配合监控告警。

6.2 做进程级内存画像

如果你想知道一个进程的内存访问模式长什么样，DAMON是个很好的工具。具体做法是：监控目标进程，跑一段时间，然后把regions文件导出，用脚本分析。

分析维度可以包括：热区占总地址空间的比例、热区的地址分布（是集中在堆还是栈还是mmap区）、访问频率的直方图分布。这些信息对优化程序的内存布局很有价值。比如你发现热区集中在几个大的mmap块里，那可能说明这些块的数据结构有优化空间。

我写过一个简单的分析脚本，把regions输出转成CSV，然后用Python画直方图。代码不复杂，核心就是解析那四列数据，然后按访问次数分桶。

6.3 多目标监控的配置技巧

DAMON支持一个实例监控多个target。配置上就是在targets/下创建多个子目录，每个指定不同的pid或地址范围。但要注意，多个target是共享同一套monitoring_attrs和schemes的，也就是说采样参数和动作规则是统一的。

如果你需要对不同target用不同的策略，那就得开多个kdamond实例。多实例的配置就是kdamonds/nr_kdamonds设成大于1，然后分别配置。多实例之间是独立的，互不影响。

多实例的代价是资源开销叠加。每个实例都有自己的采样线程和聚合逻辑，跑多了CPU和内存都会涨。我的建议是实例数不要超过CPU核数的一半，不然调度开销会很明显。

6.4 未来可能的扩展方向

DAMON还在持续演进，几个我觉得值得关注的方向。

一是更细粒度的监控。现在的region粒度受限于采样机制，最小也就到页级别。未来如果能做到更细，对某些场景会很有用。

二是更丰富的动作类型。现在的action主要是stat、cold、pageout、madvise这几种。如果能支持自定义动作（比如触发用户态回调），玩法就多了。

三是和调度器的联动。DAMON的访问数据如果能反馈给调度器，指导任务迁移和内存分配，对NUMA系统的性能优化会很有帮助。这个方向已经有了一些研究，但还没进主线。

四是硬件辅助。有些CPU提供了访问监控的硬件支持（比如Intel的PEBS、AMD的IBS），如果能和DAMON结合，精度和开销都能进一步优化。

7. 我个人的一些实操体会

DAMON这东西，我前后折腾了小半年，从最开始看文档一头雾水，到后来能熟练配置各种scheme，中间踩的坑不少。最大的体会是：别指望开箱即用。它的默认参数适合做演示，真要用到生产环境，采样参数、region上下界、scheme阈值都得根据你的实际负载调。

另一个体会是DBGFS和SYSFS要配合用。DBGFS调参方便，SYSFS部署稳定。我的做法是先在DBGFS上把参数调好，验证效果，然后再翻译成SYSFS配置部署到生产。这样既快又稳。

还有个小心得：监控结果要结合业务指标看。DAMON告诉你内存访问模式，但"这个模式是好是坏"得结合业务延迟、吞吐这些指标判断。单纯看DAMON的数据容易钻牛角尖，比如你发现某个region特别热，但它可能就是业务的核心数据结构，热是应该的，不该去优化它。

最后说个实际效果。前面提到的那个内存抖动问题，用DAMON定位后发现是一个缓存模块的冷数据没被及时回收，导致内存压力一直下不去。配了个pageoutscheme把冷数据换出后，P99延迟从原来的200ms降到了80ms左右。这个收益还是挺可观的，也让我对DAMON的实用价值有了更直观的认识。

如果你也在做内存相关的优化，DAMON值得花时间研究一下。它的学习曲线不算陡，但细节挺多，建议边看文档边动手跑，光看是看不出门道的。