1. 问题现象与初步排查：当kswapd0成为CPU“钉子户”

最近在维护一台线上服务器时，监控系统突然告警，显示某台机器的CPU使用率持续在80%以上。登录服务器一看，top命令的结果里，一个名叫kswapd0的进程赫然排在榜首，其CPU占用率长期维持在50%-70%之间，居高不下。这可不是个好兆头。kswapd0是Linux内核内存管理子系统中的一个核心守护进程，它的职责是进行页面回收（Page Reclaim），特别是当系统物理内存（RAM）紧张时，它会将不常用的内存页交换（Swap Out）到硬盘上的交换分区（Swap Space）或交换文件，以腾出物理内存。正常情况下，kswapd0应该是间歇性、低强度地工作。一旦它开始持续、高强度地占用CPU，就像消防员一直在拼命救火，说明“火情”——也就是内存压力——非常严重且持续。

遇到这种情况，很多运维或开发同学的第一反应可能是“这进程疯了，杀掉它？”。但请立刻打住这个念头。kswapd0是内核线程，你无法像杀普通进程一样kill -9它，强行干预可能导致系统不稳定甚至崩溃。正确的思路是：kswapd0高CPU不是病因，而是症状。我们的目标是找到导致内存持续紧张的根源。

首先，我们需要一套组合拳来确认问题全貌。打开终端，依次执行以下命令：

1. 确认内存与交换空间状态：

free -h

这个命令能快速查看系统总内存、已用内存、空闲内存以及缓冲/缓存（buff/cache）的使用情况，还有交换空间的总量和使用量。关键看available（可用内存）是否远小于total（总内存），以及Swap的使用量是否在持续增长。

2. 动态监控内存和交换变化：

vmstat 2 5

每隔2秒输出一次系统状态，共5次。重点关注以下几列：

• si(swap in): 每秒从交换分区读入到内存的数据量（KB）。如果持续大于0，说明系统正在从硬盘换入数据，性能已受影响。
• so(swap out): 每秒从内存写入到交换分区的数据量（KB）。如果持续很高，正是kswapd0忙碌的直观体现。
• us,sy,id: 用户态、系统态CPU时间和空闲时间。高sy（系统态）时间常与kswapd0活跃相关。
• free: 空闲内存量。
• bo,bi: 块设备读写，频繁的交换会导致这些值升高。

3. 查看更详细的内存统计：

cat /proc/meminfo | grep -E “(MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree|SwapCached|Dirty|Writeback)”

这里MemAvailable是对free命令中available的更精确估算。Dirty和Writeback页过多也会触发kswapd0积极工作，以将脏页写回磁盘。

4. 定位内存消耗大户：

ps aux --sort=-%mem | head -20

按内存使用率排序，找出前20个进程。有时罪魁祸首就是某个失控的Java应用、数据库或者缓存服务。

通过以上检查，你通常能快速判断：系统是否真的陷入了内存不足（Low Memory）的状态，以及交换活动是否频繁。如果free或MemAvailable很少，同时so持续输出，那么kswapd0的高CPU占用就是系统在拼命“挣扎求生”的表现。接下来，我们需要像侦探一样，深入挖掘是谁“吃”掉了内存。

2. 深入分析：谁在“偷走”内存？—— 内存使用细分排查

确认了内存压力存在，下一步就是精细化分析。Linux的内存管理比“已用/空闲”二分法要复杂得多。通过free看到的内存被大量用于buff/cache是正常且有益的（内核利用空闲内存缓存磁盘数据，加速IO），这部分内存会在应用需要时被快速回收。真正的危险信号是可用内存（Available）枯竭，且匿名页（Anonymous Pages，即堆、栈等不能直接对应文件的内存）开始被频繁换出。

2.1 使用smem工具进行更直观的进程内存报告

smem命令可以提供更贴近用户理解的内存报告，特别是它计算的USS（Unique Set Size，进程独占的物理内存）和PSS（Proportional Set Size，按共享比例计算的实际物理内存占用），比ps的RSS（Resident Set Size，驻留集大小，包含共享库）更准确。

# 安装smem（如未安装） sudo apt-get install smem # Debian/Ubuntu sudo yum install smem # RHEL/CentOS # 以PSS排序查看进程内存 sudo smem -s pss -r | head -20

这个列表能帮你更准确地识别真正的内存消耗巨头。

2.2 检查内核内存碎片与不可回收内存

有时，内存被一些内核数据结构或驱动占用，无法被用户空间进程使用，也无法被kswapd0回收。这被称为“不可回收的Slab内存”。可以通过以下命令检查：

cat /proc/meminfo | grep -E “(SReclaimable|SUnreclaim|Slab)”

Slab = SReclaimable + SUnreclaim。SUnreclaim过高可能意味着内核有内存泄漏（例如，某些内核模块不断分配kmalloc但不释放）。可以使用slabtop命令动态观察Slab缓存的使用情况：

sudo slabtop -s c

按缓存大小排序，观察是否有某个缓存（如dentry、inode_cache、buffer_head或某个驱动特有的缓存）异常增长。

2.3 使用pidstat监控进程级内存与交换活动

sysstat工具包中的pidstat是进程性能分析的利器。

# 安装sysstat sudo apt-get install sysstat # 每2秒报告一次所有进程的内存和交换统计，共10次 pidstat -r -u 2 10

关注%MEM（内存使用率）、RSS（驻留集大小，单位KB），以及一个关键指标：VSZ（虚拟内存大小）与RSS的比值。如果某个进程的VSZ巨大（比如几十GB）而RSS也在增长，可能意味着它在申请大量虚拟地址空间，虽然不一定立即占用物理内存，但会影响内存管理开销。更直接看交换行为的是：

pidstat -s 2 5

这个命令可以查看进程的swapin和swapout情况，直接定位到哪个进程的页面正在被换入换出。

2.4 检查透明大页（THP）的影响

透明大页（Transparent HugePages, THP）是内核的一个特性，旨在通过自动使用大内存页（通常2MB）来减少页表项（TLB）压力，提升性能。但在某些负载下（特别是数据库如MySQL、MongoDB），THP的碎片整理（khugepaged）和合并操作反而会导致性能下降和延迟抖动，有时也会加剧kswapd0的活动。

cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag

如果输出是[always]或[madvise]，并且你的应用是已知的THP不友好型（如数据库），可以尝试将其设置为never进行问题排除：

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

注意：这是临时更改，重启失效。永久修改需编辑/etc/default/grub并更新grub。修改前请评估应用兼容性。

经过这一轮深入分析，你应该能定位到是某个用户进程内存泄漏、内核Slab增长异常，还是某种内存管理策略（如THP）与工作负载不匹配。如果问题出在某个具体应用上，那么就需要针对该应用进行专项调优或问题修复。

3. 针对性调优与缓解措施：给系统“降压”

找到根源后，就可以采取相应的措施。这里分为临时缓解和长期优化。

3.1 临时应急：释放缓存与手动触发回收

如果问题突发，需要快速缓解症状，可以尝试手动释放内核的页面缓存（Page Cache）和目录项/索引节点缓存（Dentry/Inode Cache）。注意：这可能会暂时降低系统IO性能，因为清理了缓存。

# 释放页面缓存（最安全，对性能影响相对小） echo 1 | sudo tee /proc/sys/vm/drop_caches # 释放目录项和索引节点缓存 echo 2 | sudo tee /proc/sys/vm/drop_caches # 释放页面缓存、目录项和索引节点缓存 echo 3 | sudo tee /proc/sys/vm/drop_caches

执行后观察free命令的available是否增加，kswapd0的CPU是否下降。这只是一个“退烧药”，治标不治本。

另一个更温和的方法是调整内核的“脏页”写回策略，减少瞬间的IO压力。脏页是已被修改但未写回磁盘的缓存页。kswapd0在回收内存时，如果遇到脏页，需要先将其写回磁盘（同步IO），这会造成延迟。我们可以适当调高脏页比例阈值和写回时间，让内核更“懒惰”地写回，但风险是意外断电可能丢失更多数据。

# 查看当前值 cat /proc/sys/vm/dirty_ratio # 系统总内存的百分比，当脏页达到此比例，进程会被阻塞以执行写回 cat /proc/sys/vm/dirty_background_ratio # 后台写回开始的阈值 cat /proc/sys/vm/dirty_expire_centisecs # 脏页存活多久（百分之一秒）后会被写回 cat /proc/sys/vm/dirty_writeback_centisecs # 内核刷新线程唤醒间隔 # 临时调整（示例，需根据具体负载测试） echo 20 | sudo tee /proc/sys/vm/dirty_background_ratio echo 30 | sudo tee /proc/sys/vm/dirty_ratio echo 3000 | sudo tee /proc/sys/vm/dirty_expire_centisecs # 30秒 echo 500 | sudo tee /proc/sys/vm/dirty_writeback_centisecs # 5秒

3.2 长期优化：内核参数调优与资源配置

如果内存压力是常态，就需要调整内核的交换和内存回收策略。关键参数位于/proc/sys/vm/下：

• swappiness：控制内核使用交换分区的倾向性。值范围0-100，越高越积极使用交换。对于数据库或高性能应用服务器，通常建议降低此值，让内核更倾向于回收文件页缓存，而不是交换匿名页。

  cat /proc/sys/vm/swappiness # 默认值通常是60 echo 10 | sudo tee /proc/sys/vm/swappiness # 临时设置为10

  经验之谈：在拥有大量内存（如64GB以上）且IO性能一般的系统上，将swappiness设为10甚至1是常见做法。但不要设为0，在极端内存压力下，设为0可能导致OOM Killer被过早触发，而不是尝试交换。

• vfs_cache_pressure：控制内核回收用于目录项和索引节点缓存（Dentry/Inode Cache）内存的倾向。默认值100。增加该值（>100）会使内核更积极地回收这些缓存；降低（<100）则更倾向于保留。如果系统有大量小文件操作，降低此值可能提升性能，但会占用更多内存。

  echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure

• min_free_kbytes：系统保留的最小空闲内存（KB）。kswapd0会在空闲内存低于“low”水位线（由该值计算得出）时开始后台回收，低于“min”水位线时进行直接回收（同步，阻塞进程）。适当增加此值可以让内核更早开始回收，避免瞬间压力，但会减少用户可用内存。

  # 计算建议值：通常为总内存的1-3%，对于大内存机器，可以按固定大小（如1GB） # 例如，总内存64GB，取1%约为655MB echo 655360 | sudo tee /proc/sys/vm/min_free_kbytes

3.3 应用层与架构优化

这才是根本解决之道。

1. 优化应用：修复内存泄漏代码；优化数据结构，减少内存占用；对于Java应用，合理设置JVM堆大小（-Xmx,-Xms）和垃圾回收器参数，避免Full GC引起的内存震荡。
2. 调整资源配置：为内存消耗大的服务（如MySQL、Redis）单独分配足够的物理内存，并限制其使用上限（通过Cgroups或容器资源限制）。
3. 升级硬件或扩容：如果业务增长导致内存需求确实超过物理容量，最直接的方法是增加物理内存（RAM）。这比优化交换要有效得多。
4. 优化交换设备：如果必须使用交换，确保交换分区位于高性能存储上（如NVMe SSD），绝对避免使用机械硬盘作为交换分区，否则性能会急剧下降。甚至可以考虑使用zram（内存内的压缩块设备）作为交换设备，它用CPU时间换内存空间，对于内存不极度紧张但偶有波动的场景效果不错。

4. 高级诊断与工具链：使用perf和trace洞察内核行为

当常规手段难以定位深层次原因时，我们需要动用更强大的工具，直接观察内核内存回收和kswapd0的行为。perf和ftrace/trace-cmd是Linux内核性能分析的“瑞士军刀”。

4.1 使用perf进行CPU热点分析

perf可以告诉你kswapd0在CPU上到底执行了哪些内核函数，花费了多少时间。

# 记录kswapd0进程的CPU调用栈（需要sudo） sudo perf record -g -p `pgrep kswapd0` -- sleep 30 # 分析记录结果 sudo perf report

在perf report的交互界面中，你可以看到调用链（Call Graph）。如果发现kswapd0大量时间花在shrink_slab、shrink_node、try_to_free_pages或特定的文件系统函数（如ext4_writepages）上，就能进一步明确方向。例如，大量时间在shrink_slab可能指向Slab缓存问题；在ext4_writepages则说明在频繁写回脏页到ext4文件系统。

4.2 使用trace-cmd追踪内存回收事件

trace-cmd是ftrace的前端工具，可以追踪具体的内核事件。

# 安装trace-cmd sudo apt-get install trace-cmd # 追踪与内存回收相关的事件，持续10秒 sudo trace-cmd record -e kmem:* -e vmscan:* sleep 10 sudo trace-cmd report

报告会非常详细，包含事件发生的时间戳、进程、函数和参数。你可以筛选出与kswapd相关的事件，例如：

• mm_vmscan_kswapd_wake:kswapd被唤醒。
• mm_vmscan_kswapd_sleep:kswapd进入睡眠。
• mm_vmscan_lru_isolate: 隔离LRU链表中的页。
• mm_vmscan_lru_shrink_inactive: 收缩非活跃LRU链表。 通过分析这些事件的频率和参数，可以判断回收的压力来源和效率。

4.3 检查内存回收效率与“直接回收”

除了kswapd的后台回收，当内存压力极大时，申请内存的进程本身会同步地进行“直接回收”（Direct Reclaim），这会导致应用程序的延迟毛刺。我们可以通过/proc/vmstat来观察：

watch -n 1 “grep -E ‘(pgscan_kswapd|pgscan_direct|pgsteal_kswapd|pgsteal_direct|oom_kill)’ /proc/vmstat”

• pgscan_kswapd/pgscan_direct:kswapd和直接回收扫描的页数。
• pgsteal_kswapd/pgsteal_direct: 成功回收的页数。
• oom_kill: OOM Killer被触发的次数。

如果pgscan_direct和pgsteal_direct的数值很高且在快速增长，说明系统内存压力已经大到需要进程“自己动手”回收内存，这对应用性能是致命的。同时，观察pgsteal与pgscan的比值（回收成功率），如果比值很低，说明扫描了大量页面但回收的很少，可能遇到了大量不可回收的页（如mlock的页、共享内存等），需要进一步分析。

4.4 使用numactl检查NUMA架构下的内存不平衡

在多处理器（NUMA架构）的服务器上，内存访问有“本地”和“远程”之分。如果进程运行在一个NUMA节点上，却大量分配了另一个NUMA节点的内存（“跨节点访问”），会导致访问延迟增加，并在内存回收时可能引发问题。kswapd0是每个NUMA节点都有一个的（如kswapd0,kswapd1）。可以检查是否是某个特定节点的kswapd特别忙。

numastat -m

查看每个节点的内存使用情况。如果Node 0的Free远小于Node 1，而Node 0的kswapd很忙，就可能是NUMA局部性问题。可以通过numactl将内存敏感的应用绑定到特定的CPU和内存节点，或者调整内核的NUMA平衡策略（/proc/sys/kernel/numa_balancing）。

通过这一层级的诊断，你几乎可以透视内核内存管理的内部运作，精准定位是哪个子系统、哪种类型的页面回收遇到了瓶颈。这对于解决复杂、顽固的kswapd0高CPU问题至关重要。最终，结合应用日志、监控图表和内核追踪信息，形成一个完整的证据链，从而实施最有效的解决方案。