Page Cache 管理不当导致的 load 飙高——内存回收篇

本文是线上问题实战录系列的第 8 篇叙事框架：现象 → 排查过程 → 根因 → 修复 → 预防

问题现象

2026 年 6 月 17 日下午 2 点 15 分，监控告警同时触发了四条规则：

Load 飙高：CMS 图片处理节点 cms-prod-01 load average 达到 15.8（阈值 5.0）
内存不足：可用内存仅 2.3GB（可用率 7.2%）
IO 饱和：磁盘 sda 使用率 94.5%
Swap 使用率高：Swap 已使用 6.1GB/8GB（74%）

但一个令人困惑的现象是：CPU 并不忙。top 显示 CPU idle 仍有 73%，us 只有 8.5%。

告警群讨论

排查过程

第一步：观察 load 与 CPU 的背离

登录生产服务器，top 显示了一个典型的「CPU 不忙但 load 高」的状态：

top - 14:25:00 up 12 days,  3:15,  3 users,  load average: 15.8, 12.3, 8.1
Tasks: 312 total,   3 running, 307 sleeping,   2 stopped,   0 zombie
%Cpu(s):  8.5 us,  5.2 sy,  0.0 ni, 73.1 id, 12.4 wa,  0.3 hi,  0.5 si,  0.0 st

CPU idle 73%，但 load average 15.8——说明大量进程处于 不可中断睡眠（D 状态），而不是在消耗 CPU。

top 输出

更关键的线索是进程列表中出现了 kswapd0、kswapd1 和 kcompactd0——内核在拼命回收内存。

第二步：vmstat 确认 D 状态进程和内存回收

vmstat 2 6

 r  b  swpd   free   buff  cache   si   so   bi    bo    in   cs  us  sy  id  wa  st
 3 18  6057    412   1024  12408    0   45   12    48   412  892  10   5  72  13   0
 2 21  6089    386   1024  12456    0   52 1024  2048   567 1234   8   6  65  21   0

b 列 18-23：大量进程在等待 IO（D 状态）
cache 列 持续增长：Page Cache 在不断吞食内存
free 仅 412MB：32GB 内存几乎耗尽
so（swap out）约 50/秒：系统在换出页面

vmstat 输出

第三步：sar -B 量化内存回收压力

sar -B 2 5

14:25:00     pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s  %vmeff
14:25:02     1024.5   2048.0   24567.8     12.5   31245.6    289.5     34.2    256.8     79.3
14:25:04     1152.0   3072.0   28912.3     15.2   35678.9    345.6     42.1    312.5     80.6

关键指标：

pgscank/s 300+：kswapd 后台扫描的页面数，说明后台回收在全力工作
pgscand/s 30+：直接回收（direct reclaim）的页面数——进程在内存分配时被阻塞等待回收
majflt/s ~13：大量 major page fault，进程需要从磁盘读回换出的页面
%vmeff ~80%：回收效率尚可，但扫描量太高达不到平衡

sar -B 输出

第四步：查看 /proc/meminfo 确认 Page Cache 状态

cat /proc/meminfo

MemTotal:       32803572 kB
MemFree:          386224 kB
Cached:         12890124 kB
Active(file):   7555566 kB
Inactive(file): 5000000 kB
Dirty:            234567 kB
Writeback:         12345 kB
SwapTotal:       8388608 kB
SwapFree:        2185808 kB

Cached 12.9GB + Active(file) 7.5GB：Page Cache 占了几乎所有剩余内存
Dirty 234MB：大量脏页待回刷
Swap 已用 6.1GB：物理内存不足，大量匿名页被换出

proc/meminfo

第五步：iostat 确认 IO 瓶颈

iostat -x 2 5

Device      r/s     w/s    rkB/s    wkB/s  await  r_await  w_await  svctm  %util
sda      768.0   896.0  12288.0 14336.0   52.4    38.7     58.2   1.24  91.8

%util 91.8%，await 52ms——磁盘已经饱和。注意这里的 IO 不只是业务文件的读写，还包括 kswapd 换入换出产生的 IO。

iostat

第六步：perf top 确认热点在内核内存回收

sudo perf top -K -g --sort=comm -n 10

Overhead  Shared Object              Symbol
  12.45%  [kernel]                   [k] shrink_page_list
   8.23%  [kernel]                   [k] folio_referenced
   7.56%  [kernel]                   [k] page_cache_ra_unbounded
   6.89%  [kernel]                   [k] do_read_cache_folio
   6.12%  [kernel]                   [k] folio_mark_accessed
   5.78%  [kernel]                   [k] kswapd
   5.34%  [kernel]                   [k] try_to_free_pages

shrink_page_list 12.45%：内核回收页面的核心函数，说明系统在全力回收内存
page_cache_ra_unbounded + do_read_cache_folio + filemap_read：Page Cache 读取路径的热点
kswapd + try_to_free_pages：内存回收线程在工作

这是最直接的证据——CPU 时间主要消耗在内存回收路径上，而不是业务代码。

perf top

第七步：检查脏页配置

sysctl vm.dirty_ratio vm.dirty_background_ratio
vm.dirty_ratio = 30
vm.dirty_background_ratio = 10

dirty_ratio = 30%：进程可以产生脏页直到占满 30% 的内存（约 9.6GB），然后才被阻塞等待回刷。对于大文件写入场景，这会积累大量脏页，回刷时产生巨大的 IO 尖刺。

脏页配置

根因分析

问题链路

图片批量读取/写入
  → Page Cache 膨胀（12.9GB）
  → 内存不足（free 仅 400MB）
  → kswapd 启动回收
  → 回收产生 IO（换入换出 + 脏页回刷）
  → IO 阻塞进程（b 列 20+）
  → load 飙高（15.8）
  → 可用内存不足导致更多直接回收
  → 恶性循环

为什么 CPU idle 还有 73% 但 load 很高？

这是理解 Page Cache 问题的关键。load average 统计的是 R（运行）+ D（不可中断睡眠） 状态的进程数。

当大量进程在等待磁盘 IO 时，它们处于 D 状态，不消耗 CPU 但会计入 load。所以出现「CPU 不忙、load 很高」的现象时，要立即想到 IO 阻塞 或 内存回收。

为什么测试没发现？

测试环境文件数少（几十张），内存充足，Page Cache 占不满
测试时没有配合高并发用户请求，匿名页和文件页之间没有竞争
业务代码上线前只做了功能测试，没有做 IO profile 和内存压力测试

修复方案

两个方向同时进行：

方向一：代码层面——主动释放 Page Cache

// 修复前：批量读取不释放缓存
for (Path source : sourceImages) {
    byte[] imageData = Files.readAllBytes(source);
    // Page Cache 持续增长，永不释放
    byte[] resized = resizeImage(imageData, 1920, 1080);
    Files.write(outputDir.resolve(source.getFileName()), resized);
}

// 修复后：分批次处理 + MappedByteBuffer unmap 释放 Page Cache
private static final int MAX_BATCH_SIZE = 50;

private void dropPageCache(List<Path> files) throws IOException {
    for (Path file : files) {
        try (FileChannel ch = FileChannel.open(file, StandardOpenOption.READ)) {
            ch.map(MapMode.READ_ONLY, 0, ch.size());
            // unmap -> 内核收到 MADV_DONTNEED -> 释放对应 Page Cache
        }
    }
}

V1 问题代码 V2 修复代码 Git Diff

方向二：内核参数调优

内核参数配置

# /etc/sysctl.d/99-cms.conf
# 降低脏页阈值，减少突发 IO
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
# 降低 vfs_cache_pressure，优先保留目录项缓存
vm.vfs_cache_pressure = 50
# 降低 swappiness，减少不必要的 swap
vm.swappiness = 10
# 预留更多紧急内存
vm.min_free_kbytes = 524288

验证结果

修复后，监控显示：

top - 15:30:00  load average: 0.8, 3.2, 6.5
%Cpu(s):  6.5 us,  2.1 sy,  0.0 ni, 89.2 id,  1.8 wa
MiB Mem:  32034.7 total,  8245.6 free,  19876.3 used,   3912.8 buff/cache

load 从 15.8 降到 0.8
CPU idle 从 73% 恢复到 89%
free 从 400MB 恢复到 8.2GB
Swap 使用从 6GB 降到 300MB

修复后

避坑建议

1. 大文件 IO 操作必做 Page Cache 评估

所有涉及批量文件读写（读取原图、批量导出、数据同步等）的代码，必须评估 Page Cache 影响： - 文件总大小是否会超过可用内存的 50%？ - 读完后是否需要保留缓存在内存中？ - 是否可以分批次处理？

2. 用完即弃：主动释放 Page Cache 的策略

FileChannel.map + unmap：Java 层面的 MappedByteBuffer 方案
posix_fadvise(POSIX_FADV_DONTNEED)：C/JNI 层面的精准释放
O_DIRECT 绕过 Page Cache（适合大文件顺序读且只读一次的场景）

3. 内核参数调优

参数	默认值	推荐值	说明
`vm.dirty_ratio`	30	5-10	降低脏页上限，减少 IO 突刺
`vm.dirty_background_ratio`	10	3-5	后台回刷阈值
`vm.vfs_cache_pressure`	100	50-100	降低可优先保留 dentry/inode
`vm.swappiness`	60	10-30	减少不必要的 swap
`vm.min_free_kbytes`	auto	512MB+	预留紧急内存

4. 监控指标补充

系统级监控不要只看 CPU 和内存总量，必须补充以下指标：

指标	命令	说明
Page Cache 量	`/proc/meminfo` 的 Cached	缓存是否异常增长
脏页量	`/proc/meminfo` 的 Dirty	回刷压力
pgscank/pgscand	`sar -B`	后台/直接回收扫描量
D 状态进程数	`vmstat` 的 b 列	IO/内存回收阻塞
await + %util	`iostat -x`	磁盘是否饱和

5. 诊断手记

遇到「CPU 不忙但 load 高」时，排查路径：

top (CPU idle 高但 load 高)
  → vmstat (b 列高 -> D 状态进程)
    → sar -B (pgscank 高 -> 内存回收)
      → /proc/meminfo (Cached 高 -> Page Cache)
        → iostat -x (await 高 -> IO 瓶颈)
          → perf top (shrink_page_list 热 -> 确认内存回收)

附：完整命令清单

系统资源排查

top -b -n 1 | head -25                                          # 查看进程负载排行和 CPU 状态
vmstat 2 6                                                       # 查看 IO 阻塞(b列)和内存回收
sar -B 2 5                                                       # 查看 page scan/reclaim 统计
sar -W 2 3                                                       # 查看 swap 换入换出
iostat -x 2 5                                                    # 查看磁盘 IO 利用率
cat /proc/meminfo                                                # 查看 Page Cache / 脏页 / 内存分布
cat /proc/pressure/memory                                        # PSI 内存压力指标

内核热点分析

sudo perf top -K -g --sort=comm -n 10                            # 内核热力图
sudo perf top -K -g -p $(pgrep -d, -f kswapd)                    # 单独看 kswapd 线程

内核参数查看与调优

sysctl vm.dirty_ratio vm.dirty_background_ratio                   # 脏页阈值
sysctl vm.vfs_cache_pressure vm.swappiness vm.min_free_kbytes     # 内存回收相关
sysctl -w vm.dirty_ratio=10                                       # 临时调整脏页阈值

Demo 验证

mvn compile exec:java -Dexec.mainClass="cn.opencao.onlineissue.pagecachememoryreclaim.PageCacheDemo" -Dexec.args="v1"  # V1：不释放 Page Cache
mvn compile exec:java -Dexec.mainClass="cn.opencao.onlineissue.pagecachememoryreclaim.PageCacheDemo" -Dexec.args="v2"  # V2：主动释放 Page Cache

📖 全文带可复现 Demo 和排查截图 🔗 个人博客：https://opencao.cn 📺 公众号：Ai拆代码的曹操 🌟 知识星球：源阅会 (82877104)

草草聊事

Page Cache 管理不当导致的 load 飙高——内存回收篇

Page Cache 管理不当导致的 load 飙高——内存回收篇

问题现象

排查过程

第一步：观察 load 与 CPU 的背离

第二步：vmstat 确认 D 状态进程和内存回收

第三步：sar -B 量化内存回收压力

第四步：查看 /proc/meminfo 确认 Page Cache 状态

第五步：iostat 确认 IO 瓶颈

第六步：perf top 确认热点在内核内存回收

第七步：检查脏页配置

根因分析

问题链路

为什么 CPU idle 还有 73% 但 load 很高？

为什么测试没发现？

修复方案

方向一：代码层面——主动释放 Page Cache

方向二：内核参数调优

验证结果

避坑建议

1. 大文件 IO 操作必做 Page Cache 评估

2. 用完即弃：主动释放 Page Cache 的策略

3. 内核参数调优

4. 监控指标补充

5. 诊断手记

附：完整命令清单

系统资源排查

内核热点分析

内核参数查看与调优

Demo 验证