页缓存Page Cache原理与运维实践分析做运维和系统调优的人迟早会和页缓存打交道。它不是某个具体软件而是操作系统内核最基础、也最容易被误读的机制之一。我们常说“Linux 下文件读得快内存用不满”很大程度上就是页缓存在起作用而线上出现的“无故卡顿”“IO 飙高”“容器被 OOM”排查到最后也往往绕不开它。这篇内容主要面向系统运维、后端开发、SRE 这类经常和 Linux 服务器打交道的人。我会从页缓存的设计目标讲起把读文件、写文件背后的内核行为拆开再重点聊聊运维中常见的几个误区、排查工具和参数调节经验。不扯太深的内核源码尽量把每个“为什么”讲清楚让不同基础的读者都能看懂、会用。1. 页缓存解决了什么问题先搞懂它为什么存在1.1 一次读文件内核在背后做了什么先想一个问题当你执行cat读一个文件或者应用调用read()读数据时如果每读一次都从磁盘取整个系统的 IO 能力会被磁盘速度卡死。内存访问速度比机械硬盘快几个数量级比普通 SSD 也快一个数量级以上页缓存的设计初衷很简单把磁盘上读过的数据留在内存里下次再读同一份内容时直接从内存返回。你读过的每个文件页都会以“页”通常是 4KB为单位挂在内存的 LRU 链表上。第一次读时是缺页需要从磁盘加载到页缓存同时把页标记为活跃再次读同一个页时直接命中不需要碰磁盘。我举个例子一个应用每次启动都要读 200MB 的配置文件如果没有页缓存每次启动都要从磁盘拖 200MB有了页缓存第一次虽然慢但第二次以后这 200MB 大概率全在内存里启动速度能快一个数量级。数据库、Web 服务这类高并发应用命中页缓存与否性能差距是几十倍甚至上百倍。1.2 页缓存的写路径写其实没有真正落盘很多人容易忽略的是写文件同样走页缓存。进程调用write()时内核先把数据写进页缓存修改对应页的状态让它们标记为“脏页”然后真正落盘的动作是由后台的内核线程异步完成的并不发生在write()的系统调用返回之前。也就是说你看到的“写入完成”并不代表数据已经在磁盘上了。这个设计有两个直接收益一是写性能高大量小写会被合并成批量落盘减少磁盘寻道和 IO 次数二是数据会被聚合避免每写几 KB 就触发一次磁盘 IO。但也有代价代价就是断电或系统崩溃时页缓存里没来得及落盘的数据会丢失。理解了这一点之后你会明白很多运维现象为什么明明磁盘没怎么动write()却返回得飞快为什么突然断电后数据库日志里会出现“文件校验失败”或者“事务未完成”的记录——正是页缓存还没写完就被拔了电源。这里必须提一个容易混淆的概念页缓存和传统意义上的“写缓冲”不是一回事。页缓存是给所有文件 IO 用的统一缓存包含读缓存和写缓存两个角色而日志journal类文件系统里的日志缓冲区只是其中一种特定用途的小块内存区域不要混为一谈。2. 控制脏页回写的那几个关键旋钮2.1 两个核心水位dirty_background_ratio 与 dirty_ratio页缓存里的脏页不能无限累积内核必须有一套机制决定何时把脏页刷回磁盘。这套机制中最关键的是两个水位参数dirty_background_ratio默认 10表示当脏页数量占内存总量的比例达到 10% 时内核会唤醒后台回写线程比如flush线程开始异步刷盘。这个刷盘是温和的不会阻塞应用程序。dirty_ratio默认 20不同内核版本略有差异表示当脏页比例达到 20% 时内核会强制同步阻塞所有产生脏页的进程都可能被卡住直到脏页比例降下来。用生活化的类比家里有个垃圾桶扔到七分满时保洁员会来倒一次background但如果一直没人倒扔到楼道的垃圾已经挡路了ratio那就得停下来等清扫完毕才能继续扔。内存越大这两个比例对应的绝对量越大。比如一台 64GB 内存的机器默认配置下允许攒到 6.4GB 脏页才触发后台回写到 12.8GB 才强制阻塞。这个量级对普通业务问题不大但对写密集型业务来说可能要思考是否需要调小。2.2 回写线程与老化时间dirty_expire_centisecs 和 dirty_writeback_centisecs除了水位触发内核也靠“时间”触发回写。两个参数经常一起出现dirty_writeback_centisecs默认 500单位是百分之一秒即 5 秒。内核的 flusher 线程每隔这么长时间醒来一次检查是否有脏页需要处理。dirty_expire_centisecs默认 3000即 30 秒。表示一个脏页在页缓存里“存活”超过 30 秒后就必须在下次 flusher 醒来时被写回。这两个参数本质上是双保险水位负责控制“量”时间负责控制“龄”。即使脏页总量不高也不能让数据无限期待在内存里否则一次断电丢的数据会太多。所以你会看到即使业务不忙磁盘上也会周期性地出现一点写流量那通常是 flusher 在把“老”脏页落盘。还有一种常见误区以为调大dirty_expire_centisecs能减少磁盘写放大。实际上对机械盘环境这个判断基本正确但对 SSD 或云盘长期保留过多脏页反而会增加掉电风险而且掉电后恢复时间会变长。云服务器尤其要注意因为底层并不是本地磁盘掉电后丢失脏页的后果是数据直接没了没有传统 RAID 卡兜底。2.3 参数调整实战调参之前先想清楚你的 IO 模型不同的业务对“脏页”的态度完全不同我总结了两类典型场景。场景一在线交易类、数据库服务器、金融业务。这类业务最怕的是掉电丢数据。建议把dirty_background_ratio调低到 5dirty_ratio调低到 10 或 15让脏页尽快落盘。作为代价写性能会有所下降但换来了可靠性的提升。这类机器上同时建议把文件系统关闭atime更新mount -o noatime减少无意义的读改写流量。场景二离线计算、日志写入、批量导入。这类业务写多读少且能容忍一定程度的数据丢失。可以稍微调高 background 水位减少回写频率、提高写吞吐。但我不建议把dirty_ratio调得过高因为一旦触发强制同步会造成长时间的写停顿反而不如让它频繁一点地后台回写。调参前还有一件事必须做先看一眼当前的脏页量和磁盘吞吐能力。如果磁盘本身很慢比如普通机械盘即使调高水位后台回写也追不上业务产生脏页的速度最终还是会触发强制同步表现为周期性卡顿。这种情况下先解决磁盘性能比调参更有效。注意dirty_background_ratio和dirty_ratio的比值默认是 10/20也就是强制阻塞发生在后台回写启动后的脏页继续翻倍时。这个 2 倍的关系有一定设计直觉但实际中很多人把两个都调成一样这就会导致后台回写刚启动就立刻进入强制同步完全失去“背景刷盘”的意义不建议这样做。3. 运维中最容易误解的几个现象3.1 为什么 free 显示内存剩很多却还是出现内存压力free命令输出的第二行很迷惑人available很大但进程还是分配不到内存。这里的核心在于页缓存里的内存是可以回收的但回收它不是免费的需要额外的时间。页缓存里的干净页可以直接丢弃脏页则需要写回磁盘后才能丢弃。当系统内存紧张时内核要一边回收页缓存一边分配新页面给应用。如果脏页太多回收动作就会触发大量写盘操作表现为卡顿甚至因为等待太久而直接 OOM。所以判断一台机器是否内存紧张不要只看free里的available更要关注/proc/meminfo里的Dirty和Writeback。这两个值高说明内存里有大量脏数据等着落盘这时任何需要内存的操作都可能被拖慢。我曾经遇到一台机器available显示还有 20GB但应用频繁 OOM一查发现Dirty高达 15GB后台回写线程根本忙不过来新进程申请内存时被迫等待刷盘耗尽 memcg 限额后直接被杀。原因就是某业务写了一个超大文件且没注意落盘的节奏。3.2 为什么缓存一多容器或进程就被 OOM这个现象在容器环境里特别常见。宿主机上跑着很多容器其中某些容器是“缓存大户”比如频繁读同一个大文件的应用。容器的内存 cgroup尤其是版本 1 的 memory limit统计了该容器内所有进程使用的 page cache 计入该容器包括它们读文件时产生的页缓存。举个例子一个容器限制内存 2GB进程只占用 500MB但读了一个 2GB 的文件就会有约 1.5GB 的页缓存计入容器。当容器里再启动新进程时发现连回收带分配都赶不上直接 OOM。从宿主机看内存明明很充足但容器本身却被 cgroup 卡死。解决思路有几个方向一是用posix_fadvise配合POSIX_FADV_DONTNEED在应用层主动丢弃不需要的缓存二是考虑分拆容器避免一个容器读超大文件三是用 cgroup 版本 2 的memory.reclaim接口做主动回收或者在容器内做drop_caches的精细管理。经验值参考一个容器里如果频繁读超过容器限额一半以上的文件建议直接考虑把它改成独立宿主机部署或者接受这种缓存占用情况并调大容器限额。否则排查 OOM 会非常痛苦。3.3 为什么 drop_caches 之后应用反而变慢很多人想“释放内存”时会执行echo 3 /proc/sys/vm/drop_caches。这个操作本身是安全的它只清理页缓存中的干净页不碰脏页不杀进程。但问题是清掉之后你确实看到free变大了但应用下一次读同样的文件又得从磁盘重新加载速度会明显变慢。短时间看着内存“释放”了实际上是把有用的提前缓存变成了重复读盘的延迟。运维上真正该做的不是手动清理缓存而是搞清楚为什么缓存快速增长、是不是有应用在反复读同一批文件、以及是否需要做缓存预热。缓存不是越多越坏事空着才浪费。另外drop_caches对进程实际占用的内存毫无帮助。如果你的目标是解决“应用 OOM”这个操作并不解决问题——应用 OOM 是因为它自己申请的内存超过限制不是因为缓存占了内存。把缓存清掉过几分钟它又会涨回原来的样子除非业务不再读那些文件。3.4 为什么缓存回收时偶发卡顿或者 IO 飙高这是页缓存最典型的副作用之一。机器平时运行平稳突然磁盘写流量飙升、应用响应变慢但业务并没有提交大的写请求。这时候多半是内核在进行缓存回收把长期不用的活跃页和脏页一起刷出去。内核的回收是异步的但它不会只回收“空闲的干净页”。在内存压力下它会先尝试回收 inactive 列表中的页如果不够就会把 active 列表中的页降级甚至会触发kswapd的同步回收。同步回收意味着正在申请内存的进程要等待页缓存被刷盘后才能继续执行这就是卡顿的来源。这里的“卡顿”其实来自内核为了保住内存分配成功而主动牺牲的响应时间。调整的方向不是禁用回收而是让回收更平滑比如增大vm.vfs_cache_pressure或调低vm.swappiness可能改变回收的倾向但要先明确你的场景是“刷盘慢”还是“扫描慢”。前者需要调低水位后者需要提前清理缓存或换更快的磁盘。4. 系统排查工具与实战命令4.1 一眼看穿内存分布/proc/meminfo排查页缓存问题第一个要看的是/proc/meminfo。它里面几乎列出了所有内存状态的原始数据比free详细得多。重点看这几个字段Cache页缓存的总量包括文件缓存和 tmpfs/shmem。注意它包含Dirty和Writeback的部分。Dirty已经标记为脏页、等待写回的量。Writeback正在写回磁盘的量。这个值持续很高通常意味着磁盘吐出速度跟不上脏页积累速度。Mapped被进程映射到地址空间的页缓存部分。这个概念常见于排查“进程到底消耗了多少缓存”。Shmemtmpfs 和共享内存占用的部分。它虽然也算缓存但回收行为比文件页困难需要特别关注。AnonPages匿名内存即进程私有堆栈等不能像文件缓存那样直接丢弃。看这些字段时我习惯先看Dirty比例。如果Dirty长时间超过内存总量的 10%说明后台回写跟不上如果还伴随Writeback高基本可以确认磁盘是瓶颈。反过来如果Dirty很小但Cache很大说明你的业务只是读得多、写很少基本不需要调回写参数。4.2 精确定位谁在消耗缓存mincore、fincore 与 pcstat有时候/proc/meminfo只能告诉你“缓存总共占了多少”但你要知道“哪个文件占了多少”。此时可以借助三个工具来定位。mincoreLinux 提供的系统调用能查询指定文件哪些页已经映射到内存。写个脚本可以遍历目录下的文件算出每个文件的缓存命中率。fincore本质上是对mincore的封装输出文件占用的页数、大小和驻留内存的比例。pcstat一个更直观的工具针对每个文件显示是否已在页缓存中、缓存了多大。适合快速判断“这个文件读起来是否快”。排查一个经典场景某应用启动慢怀疑是冷启动读盘导致。先用pcstat看一下核心 jar 包或配置目录下的文件是否都在缓存里如果命中率很低就说明每次重启都需要重新加载可以考虑提前预热或者扩展应用启动逻辑。如果命中率很高但还是慢那就是应用层的问题别再把锅甩给页缓存。4.3 验证脏页回写速度sar -B 与 vmstat回写慢不慢不能靠猜得看监控数据。两个命令很实用vmstat 1观察siswap in、soswap out、bo块设备写这些字段。bo高通常对应着页缓存回写或者文件系统日志刷盘。如果bo长期高且si/so低大概率是缓存回写而不是 swap。sar -B 1重点看pgscank/s、pgsteal/s、%vmeff这几个字段。pgscank表示 kswapd 每秒扫描的页数pgsteal表示回收的页数%vmeff是回收效率。如果扫描很多但回收很少说明内存里大多是活跃页或不可回收页回收动作会对性能造成显著影响。出现“扫描多、回收少”的情况时可以给vfs_cache_pressure加值默认 100可调整到 200 或更高来加速回收文件类缓存。但要防止调得太激进导致文件缓存被频繁清空反而让业务失去缓存优势。一般从 100 调到 150 起步观察一天再做下一步。4.4 从数据反推业务读写模式排查到最后往往要落地到“这个业务到底是读多写少还是写多读少”。用一段时间的sar -B、/proc/meminfo和业务日志可以联合判断如果Dirty长期维持高位同时业务写入量大说明回写参数和磁盘能力需要审视。如果Cache很大但Dirty很小说明是读密集场景回写参数基本不用动反而要关注内存回收策略避免缓存被过度压制。如果Writeback频繁出现尖峰且尖峰时间点与业务低谷重合说明后台回写正在集中刷盘可以考虑调低dirty_background_ratio让刷盘变得更平稳虽然总写盘量不变但避免了对业务高峰的叠加影响。这种“反推”的过程比直接抄别人的参数有意义得多。不同机器的磁盘速度、内存大小、业务模型差异极大没有一套配置能通吃关键是把每个数字的含义和对应行为吃透。5. 常见问题排查与避坑清单5.1 常见问题速查表现象可能原因排查方向常规解决方案应用启动慢读文件延迟高页缓存未命中冷启动读盘pcstat查看文件缓存命中率预热关键文件用readahead或提前加载减少全量扫描服务器莫名 OOM但 available 很大脏页堆积导致回收阻塞看/proc/meminfo的Dirty、Writeback调低 dirty 水位换更快的磁盘限流写量容器频繁被杀宿主内存充足容器 cgroup 计入过多 page cache检查容器内存统计观察文件读取大小调整容器限额分拆大文件读取场景主动FADV_DONTNEED定期出现磁盘写尖峰flusher 批量回写脏页sar -B看回写数量结合业务低谷时段调低 dirty_background_ratio 平滑刷盘或根据业务接受度调整drop_caches 后应用变慢清除了有用缓存重新读盘回看 drop_caches 的操作记录不主动清理缓存排查是否有不合理的缓存增长内存长时间高占用页缓存量大属于正常状态/proc/meminfo的Cache与AnonPages比例一般无需处理若担心可用性可关注 available 而非 total5.2 实战中的几个“不做什么”原则第一不要在业务高峰前大规模drop_caches。你以为是在“清理内存”实际上是在给高峰期的 IO 埋雷。如果确实需要安排在业务低谷做而且只做echo 1清理页缓存不要直接echo 3把 dentry 和 inode 缓存也一起清掉否则路径解析也会变慢。第二不要为了追求“数据安全”把 dirty_ratio 调得极低。比如设成 2 或 1会导致写文件频繁阻塞性能损失极大而且并不能保证掉电不丢数据——只有fsync才是可靠的落盘保障。页缓存只是内核的缓存层真正要保证可靠性得靠应用层正确地调用fsync或者使用支持持久化语义的库/数据库。第三不要只用free判断内存状况。free只给了一个总量和剩余量信息粒度太粗。运维监控系统里应持续采集/proc/meminfo的关键字段以及sar -B的扫描与回收数据才能看到趋势而不是等到出事的那一秒才意识到问题。第四不要忽略 cgroup 和容器的视角。不管宿主机内存多大容器中的进程各自有独立的限额和统计。排查任何容器 OOM先把该容器memory.usage_in_bytes和memory.stat打开看看分清到底是匿名内存页在涨还是 page cache 在涨再做对应的限制或调优。页缓存不是一个需要“消灭”的东西它本身就是操作系统最有效率的加速器之一。真正的运维功夫在于看懂它的行为规律判断它什么时候是帮手、什么时候是隐患然后用参数和工具把它控制在对业务最有利的区间。平时我在实际排查中最常用的组合就是/proc/meminfo加sar -B加pcstat三件套基本能覆盖八成的缓存问题。你遇到搞不定的性能问题时不妨先看看这三个输出大概率能发现之前忽略的线索。
页缓存Page Cache原理与运维实践分析做运维和系统调优的人迟早会和页缓存打交道。它不是某个具体软件而是操作系统内核最基础、也最容易被误读的机制之一。我们常说“Linux 下文件读得快内存用不满”很大程度上就是页缓存在起作用而线上出现的“无故卡顿”“IO 飙高”“容器被 OOM”排查到最后也往往绕不开它。这篇内容主要面向系统运维、后端开发、SRE 这类经常和 Linux 服务器打交道的人。我会从页缓存的设计目标讲起把读文件、写文件背后的内核行为拆开再重点聊聊运维中常见的几个误区、排查工具和参数调节经验。不扯太深的内核源码尽量把每个“为什么”讲清楚让不同基础的读者都能看懂、会用。1. 页缓存解决了什么问题先搞懂它为什么存在1.1 一次读文件内核在背后做了什么先想一个问题当你执行cat读一个文件或者应用调用read()读数据时如果每读一次都从磁盘取整个系统的 IO 能力会被磁盘速度卡死。内存访问速度比机械硬盘快几个数量级比普通 SSD 也快一个数量级以上页缓存的设计初衷很简单把磁盘上读过的数据留在内存里下次再读同一份内容时直接从内存返回。你读过的每个文件页都会以“页”通常是 4KB为单位挂在内存的 LRU 链表上。第一次读时是缺页需要从磁盘加载到页缓存同时把页标记为活跃再次读同一个页时直接命中不需要碰磁盘。我举个例子一个应用每次启动都要读 200MB 的配置文件如果没有页缓存每次启动都要从磁盘拖 200MB有了页缓存第一次虽然慢但第二次以后这 200MB 大概率全在内存里启动速度能快一个数量级。数据库、Web 服务这类高并发应用命中页缓存与否性能差距是几十倍甚至上百倍。1.2 页缓存的写路径写其实没有真正落盘很多人容易忽略的是写文件同样走页缓存。进程调用write()时内核先把数据写进页缓存修改对应页的状态让它们标记为“脏页”然后真正落盘的动作是由后台的内核线程异步完成的并不发生在write()的系统调用返回之前。也就是说你看到的“写入完成”并不代表数据已经在磁盘上了。这个设计有两个直接收益一是写性能高大量小写会被合并成批量落盘减少磁盘寻道和 IO 次数二是数据会被聚合避免每写几 KB 就触发一次磁盘 IO。但也有代价代价就是断电或系统崩溃时页缓存里没来得及落盘的数据会丢失。理解了这一点之后你会明白很多运维现象为什么明明磁盘没怎么动write()却返回得飞快为什么突然断电后数据库日志里会出现“文件校验失败”或者“事务未完成”的记录——正是页缓存还没写完就被拔了电源。这里必须提一个容易混淆的概念页缓存和传统意义上的“写缓冲”不是一回事。页缓存是给所有文件 IO 用的统一缓存包含读缓存和写缓存两个角色而日志journal类文件系统里的日志缓冲区只是其中一种特定用途的小块内存区域不要混为一谈。2. 控制脏页回写的那几个关键旋钮2.1 两个核心水位dirty_background_ratio 与 dirty_ratio页缓存里的脏页不能无限累积内核必须有一套机制决定何时把脏页刷回磁盘。这套机制中最关键的是两个水位参数dirty_background_ratio默认 10表示当脏页数量占内存总量的比例达到 10% 时内核会唤醒后台回写线程比如flush线程开始异步刷盘。这个刷盘是温和的不会阻塞应用程序。dirty_ratio默认 20不同内核版本略有差异表示当脏页比例达到 20% 时内核会强制同步阻塞所有产生脏页的进程都可能被卡住直到脏页比例降下来。用生活化的类比家里有个垃圾桶扔到七分满时保洁员会来倒一次background但如果一直没人倒扔到楼道的垃圾已经挡路了ratio那就得停下来等清扫完毕才能继续扔。内存越大这两个比例对应的绝对量越大。比如一台 64GB 内存的机器默认配置下允许攒到 6.4GB 脏页才触发后台回写到 12.8GB 才强制阻塞。这个量级对普通业务问题不大但对写密集型业务来说可能要思考是否需要调小。2.2 回写线程与老化时间dirty_expire_centisecs 和 dirty_writeback_centisecs除了水位触发内核也靠“时间”触发回写。两个参数经常一起出现dirty_writeback_centisecs默认 500单位是百分之一秒即 5 秒。内核的 flusher 线程每隔这么长时间醒来一次检查是否有脏页需要处理。dirty_expire_centisecs默认 3000即 30 秒。表示一个脏页在页缓存里“存活”超过 30 秒后就必须在下次 flusher 醒来时被写回。这两个参数本质上是双保险水位负责控制“量”时间负责控制“龄”。即使脏页总量不高也不能让数据无限期待在内存里否则一次断电丢的数据会太多。所以你会看到即使业务不忙磁盘上也会周期性地出现一点写流量那通常是 flusher 在把“老”脏页落盘。还有一种常见误区以为调大dirty_expire_centisecs能减少磁盘写放大。实际上对机械盘环境这个判断基本正确但对 SSD 或云盘长期保留过多脏页反而会增加掉电风险而且掉电后恢复时间会变长。云服务器尤其要注意因为底层并不是本地磁盘掉电后丢失脏页的后果是数据直接没了没有传统 RAID 卡兜底。2.3 参数调整实战调参之前先想清楚你的 IO 模型不同的业务对“脏页”的态度完全不同我总结了两类典型场景。场景一在线交易类、数据库服务器、金融业务。这类业务最怕的是掉电丢数据。建议把dirty_background_ratio调低到 5dirty_ratio调低到 10 或 15让脏页尽快落盘。作为代价写性能会有所下降但换来了可靠性的提升。这类机器上同时建议把文件系统关闭atime更新mount -o noatime减少无意义的读改写流量。场景二离线计算、日志写入、批量导入。这类业务写多读少且能容忍一定程度的数据丢失。可以稍微调高 background 水位减少回写频率、提高写吞吐。但我不建议把dirty_ratio调得过高因为一旦触发强制同步会造成长时间的写停顿反而不如让它频繁一点地后台回写。调参前还有一件事必须做先看一眼当前的脏页量和磁盘吞吐能力。如果磁盘本身很慢比如普通机械盘即使调高水位后台回写也追不上业务产生脏页的速度最终还是会触发强制同步表现为周期性卡顿。这种情况下先解决磁盘性能比调参更有效。注意dirty_background_ratio和dirty_ratio的比值默认是 10/20也就是强制阻塞发生在后台回写启动后的脏页继续翻倍时。这个 2 倍的关系有一定设计直觉但实际中很多人把两个都调成一样这就会导致后台回写刚启动就立刻进入强制同步完全失去“背景刷盘”的意义不建议这样做。3. 运维中最容易误解的几个现象3.1 为什么 free 显示内存剩很多却还是出现内存压力free命令输出的第二行很迷惑人available很大但进程还是分配不到内存。这里的核心在于页缓存里的内存是可以回收的但回收它不是免费的需要额外的时间。页缓存里的干净页可以直接丢弃脏页则需要写回磁盘后才能丢弃。当系统内存紧张时内核要一边回收页缓存一边分配新页面给应用。如果脏页太多回收动作就会触发大量写盘操作表现为卡顿甚至因为等待太久而直接 OOM。所以判断一台机器是否内存紧张不要只看free里的available更要关注/proc/meminfo里的Dirty和Writeback。这两个值高说明内存里有大量脏数据等着落盘这时任何需要内存的操作都可能被拖慢。我曾经遇到一台机器available显示还有 20GB但应用频繁 OOM一查发现Dirty高达 15GB后台回写线程根本忙不过来新进程申请内存时被迫等待刷盘耗尽 memcg 限额后直接被杀。原因就是某业务写了一个超大文件且没注意落盘的节奏。3.2 为什么缓存一多容器或进程就被 OOM这个现象在容器环境里特别常见。宿主机上跑着很多容器其中某些容器是“缓存大户”比如频繁读同一个大文件的应用。容器的内存 cgroup尤其是版本 1 的 memory limit统计了该容器内所有进程使用的 page cache 计入该容器包括它们读文件时产生的页缓存。举个例子一个容器限制内存 2GB进程只占用 500MB但读了一个 2GB 的文件就会有约 1.5GB 的页缓存计入容器。当容器里再启动新进程时发现连回收带分配都赶不上直接 OOM。从宿主机看内存明明很充足但容器本身却被 cgroup 卡死。解决思路有几个方向一是用posix_fadvise配合POSIX_FADV_DONTNEED在应用层主动丢弃不需要的缓存二是考虑分拆容器避免一个容器读超大文件三是用 cgroup 版本 2 的memory.reclaim接口做主动回收或者在容器内做drop_caches的精细管理。经验值参考一个容器里如果频繁读超过容器限额一半以上的文件建议直接考虑把它改成独立宿主机部署或者接受这种缓存占用情况并调大容器限额。否则排查 OOM 会非常痛苦。3.3 为什么 drop_caches 之后应用反而变慢很多人想“释放内存”时会执行echo 3 /proc/sys/vm/drop_caches。这个操作本身是安全的它只清理页缓存中的干净页不碰脏页不杀进程。但问题是清掉之后你确实看到free变大了但应用下一次读同样的文件又得从磁盘重新加载速度会明显变慢。短时间看着内存“释放”了实际上是把有用的提前缓存变成了重复读盘的延迟。运维上真正该做的不是手动清理缓存而是搞清楚为什么缓存快速增长、是不是有应用在反复读同一批文件、以及是否需要做缓存预热。缓存不是越多越坏事空着才浪费。另外drop_caches对进程实际占用的内存毫无帮助。如果你的目标是解决“应用 OOM”这个操作并不解决问题——应用 OOM 是因为它自己申请的内存超过限制不是因为缓存占了内存。把缓存清掉过几分钟它又会涨回原来的样子除非业务不再读那些文件。3.4 为什么缓存回收时偶发卡顿或者 IO 飙高这是页缓存最典型的副作用之一。机器平时运行平稳突然磁盘写流量飙升、应用响应变慢但业务并没有提交大的写请求。这时候多半是内核在进行缓存回收把长期不用的活跃页和脏页一起刷出去。内核的回收是异步的但它不会只回收“空闲的干净页”。在内存压力下它会先尝试回收 inactive 列表中的页如果不够就会把 active 列表中的页降级甚至会触发kswapd的同步回收。同步回收意味着正在申请内存的进程要等待页缓存被刷盘后才能继续执行这就是卡顿的来源。这里的“卡顿”其实来自内核为了保住内存分配成功而主动牺牲的响应时间。调整的方向不是禁用回收而是让回收更平滑比如增大vm.vfs_cache_pressure或调低vm.swappiness可能改变回收的倾向但要先明确你的场景是“刷盘慢”还是“扫描慢”。前者需要调低水位后者需要提前清理缓存或换更快的磁盘。4. 系统排查工具与实战命令4.1 一眼看穿内存分布/proc/meminfo排查页缓存问题第一个要看的是/proc/meminfo。它里面几乎列出了所有内存状态的原始数据比free详细得多。重点看这几个字段Cache页缓存的总量包括文件缓存和 tmpfs/shmem。注意它包含Dirty和Writeback的部分。Dirty已经标记为脏页、等待写回的量。Writeback正在写回磁盘的量。这个值持续很高通常意味着磁盘吐出速度跟不上脏页积累速度。Mapped被进程映射到地址空间的页缓存部分。这个概念常见于排查“进程到底消耗了多少缓存”。Shmemtmpfs 和共享内存占用的部分。它虽然也算缓存但回收行为比文件页困难需要特别关注。AnonPages匿名内存即进程私有堆栈等不能像文件缓存那样直接丢弃。看这些字段时我习惯先看Dirty比例。如果Dirty长时间超过内存总量的 10%说明后台回写跟不上如果还伴随Writeback高基本可以确认磁盘是瓶颈。反过来如果Dirty很小但Cache很大说明你的业务只是读得多、写很少基本不需要调回写参数。4.2 精确定位谁在消耗缓存mincore、fincore 与 pcstat有时候/proc/meminfo只能告诉你“缓存总共占了多少”但你要知道“哪个文件占了多少”。此时可以借助三个工具来定位。mincoreLinux 提供的系统调用能查询指定文件哪些页已经映射到内存。写个脚本可以遍历目录下的文件算出每个文件的缓存命中率。fincore本质上是对mincore的封装输出文件占用的页数、大小和驻留内存的比例。pcstat一个更直观的工具针对每个文件显示是否已在页缓存中、缓存了多大。适合快速判断“这个文件读起来是否快”。排查一个经典场景某应用启动慢怀疑是冷启动读盘导致。先用pcstat看一下核心 jar 包或配置目录下的文件是否都在缓存里如果命中率很低就说明每次重启都需要重新加载可以考虑提前预热或者扩展应用启动逻辑。如果命中率很高但还是慢那就是应用层的问题别再把锅甩给页缓存。4.3 验证脏页回写速度sar -B 与 vmstat回写慢不慢不能靠猜得看监控数据。两个命令很实用vmstat 1观察siswap in、soswap out、bo块设备写这些字段。bo高通常对应着页缓存回写或者文件系统日志刷盘。如果bo长期高且si/so低大概率是缓存回写而不是 swap。sar -B 1重点看pgscank/s、pgsteal/s、%vmeff这几个字段。pgscank表示 kswapd 每秒扫描的页数pgsteal表示回收的页数%vmeff是回收效率。如果扫描很多但回收很少说明内存里大多是活跃页或不可回收页回收动作会对性能造成显著影响。出现“扫描多、回收少”的情况时可以给vfs_cache_pressure加值默认 100可调整到 200 或更高来加速回收文件类缓存。但要防止调得太激进导致文件缓存被频繁清空反而让业务失去缓存优势。一般从 100 调到 150 起步观察一天再做下一步。4.4 从数据反推业务读写模式排查到最后往往要落地到“这个业务到底是读多写少还是写多读少”。用一段时间的sar -B、/proc/meminfo和业务日志可以联合判断如果Dirty长期维持高位同时业务写入量大说明回写参数和磁盘能力需要审视。如果Cache很大但Dirty很小说明是读密集场景回写参数基本不用动反而要关注内存回收策略避免缓存被过度压制。如果Writeback频繁出现尖峰且尖峰时间点与业务低谷重合说明后台回写正在集中刷盘可以考虑调低dirty_background_ratio让刷盘变得更平稳虽然总写盘量不变但避免了对业务高峰的叠加影响。这种“反推”的过程比直接抄别人的参数有意义得多。不同机器的磁盘速度、内存大小、业务模型差异极大没有一套配置能通吃关键是把每个数字的含义和对应行为吃透。5. 常见问题排查与避坑清单5.1 常见问题速查表现象可能原因排查方向常规解决方案应用启动慢读文件延迟高页缓存未命中冷启动读盘pcstat查看文件缓存命中率预热关键文件用readahead或提前加载减少全量扫描服务器莫名 OOM但 available 很大脏页堆积导致回收阻塞看/proc/meminfo的Dirty、Writeback调低 dirty 水位换更快的磁盘限流写量容器频繁被杀宿主内存充足容器 cgroup 计入过多 page cache检查容器内存统计观察文件读取大小调整容器限额分拆大文件读取场景主动FADV_DONTNEED定期出现磁盘写尖峰flusher 批量回写脏页sar -B看回写数量结合业务低谷时段调低 dirty_background_ratio 平滑刷盘或根据业务接受度调整drop_caches 后应用变慢清除了有用缓存重新读盘回看 drop_caches 的操作记录不主动清理缓存排查是否有不合理的缓存增长内存长时间高占用页缓存量大属于正常状态/proc/meminfo的Cache与AnonPages比例一般无需处理若担心可用性可关注 available 而非 total5.2 实战中的几个“不做什么”原则第一不要在业务高峰前大规模drop_caches。你以为是在“清理内存”实际上是在给高峰期的 IO 埋雷。如果确实需要安排在业务低谷做而且只做echo 1清理页缓存不要直接echo 3把 dentry 和 inode 缓存也一起清掉否则路径解析也会变慢。第二不要为了追求“数据安全”把 dirty_ratio 调得极低。比如设成 2 或 1会导致写文件频繁阻塞性能损失极大而且并不能保证掉电不丢数据——只有fsync才是可靠的落盘保障。页缓存只是内核的缓存层真正要保证可靠性得靠应用层正确地调用fsync或者使用支持持久化语义的库/数据库。第三不要只用free判断内存状况。free只给了一个总量和剩余量信息粒度太粗。运维监控系统里应持续采集/proc/meminfo的关键字段以及sar -B的扫描与回收数据才能看到趋势而不是等到出事的那一秒才意识到问题。第四不要忽略 cgroup 和容器的视角。不管宿主机内存多大容器中的进程各自有独立的限额和统计。排查任何容器 OOM先把该容器memory.usage_in_bytes和memory.stat打开看看分清到底是匿名内存页在涨还是 page cache 在涨再做对应的限制或调优。页缓存不是一个需要“消灭”的东西它本身就是操作系统最有效率的加速器之一。真正的运维功夫在于看懂它的行为规律判断它什么时候是帮手、什么时候是隐患然后用参数和工具把它控制在对业务最有利的区间。平时我在实际排查中最常用的组合就是/proc/meminfo加sar -B加pcstat三件套基本能覆盖八成的缓存问题。你遇到搞不定的性能问题时不妨先看看这三个输出大概率能发现之前忽略的线索。
