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命令可以提供更贴近用户理解的内存报告特别是它计算的USSUnique Set Size进程独占的物理内存和PSSProportional Set Size按共享比例计算的实际物理内存占用比ps的RSSResident 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、MongoDBTHP的碎片整理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_pressuremin_free_kbytes系统保留的最小空闲内存KB。kswapd0会在空闲内存低于“low”水位线由该值计算得出时开始后台回收低于“min”水位线时进行直接回收同步阻塞进程。适当增加此值可以让内核更早开始回收避免瞬间压力但会减少用户可用内存。# 计算建议值通常为总内存的1-3%对于大内存机器可以按固定大小如1GB # 例如总内存64GB取1%约为655MB echo 655360 | sudo tee /proc/sys/vm/min_free_kbytes3.3 应用层与架构优化这才是根本解决之道。优化应用修复内存泄漏代码优化数据结构减少内存占用对于Java应用合理设置JVM堆大小-Xmx,-Xms和垃圾回收器参数避免Full GC引起的内存震荡。调整资源配置为内存消耗大的服务如MySQL、Redis单独分配足够的物理内存并限制其使用上限通过Cgroups或容器资源限制。升级硬件或扩容如果业务增长导致内存需求确实超过物理容量最直接的方法是增加物理内存RAM。这比优化交换要有效得多。优化交换设备如果必须使用交换确保交换分区位于高性能存储上如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问题至关重要。最终结合应用日志、监控图表和内核追踪信息形成一个完整的证据链从而实施最有效的解决方案。
