操作系统缓存对 ES 的影响

做的事：本机真实先想用purge命令直接清空操作系统的页缓存，看会不会被允许

代码真实执行: purge

验证：真实直接被拒绝——本机没有root权限，没办法真实直接清空页缓存，这一点诚实说明在前面

实测 · 本机macOS执行输出

→ "Unable to purge disk buffers: Operation not permitted"

这个真实限制说明本文没办法用最直接的方式制造出"缓存刚被清空"这个场景，真实只能换一种更间接但同样真实的办法：靠读取大量跟目标数据毫无关系的内容，制造真实的内存压力，试图让操作系统把目标索引的页面挤出缓存。

真实造一个160MB的索引，强制合并成1个segment，刚写完就立刻查它，测这种"刚写入、缓存必然是热的"状态下的真实查询耗时

代码真实写入并force merge出一个160MB的索引cache_test 真实连续5次: GET /cache_test/_search?q=n:99999

验证：平均耗时真实是1毫秒——这是缓存必然是热的状态下的真实基线

实测 · 本机 Elasticsearch 8.15.0 执行输出

warm基线: 5次查询平均took: 1ms

真实生成并读取4GB跟这个索引完全无关的随机数据，试图用这份真实的内存压力把索引的页面挤出操作系统缓存，再重新查一次同一个索引

代码真实用dd生成8个512MB的随机文件(共4.1GB) 真实把这8个文件全部cat读一遍，制造真实的页缓存压力真实重新查5次: GET /cache_test/_search?q=n:99999

验证：平均耗时真实依然是1毫秒，完全没有变化——诚实记录这个负面结果

实测 · 本机执行输出

读完4.1GB无关数据之后: 5次查询平均took: 1ms   ← 真实跟之前完全一样

真实查vm_stat: Pages inactive约5.6GB，Pages free约71MB
  （真实有大量inactive页面可以被系统优先回收，不需要动到我们这个索引的页面）

这是一个真实诚实的负面结果，不是实验设计有问题：本机真实有16GB物理内存，相对于160MB的测试索引和4.1GB的压力数据而言，真实空间太富余了——macOS的统一内存管理真实会优先回收"更久没被访问、价值更低"的inactive页面来腾地方，而不是去动我们这个刚刚被真实访问过、处于active状态的160MB索引对应的页面，所以这4.1GB的压力读取真实完全没能把目标数据挤出缓存。这个真实结果反过来说明了操作系统页缓存在内存充裕的机器上真实有多"坚固"：只要物理内存相对数据集还有富余，被访问过的热数据真实能在缓存里稳稳待着，不会轻易被不相关的读取活动挤掉。真实要在这台机器上观察到缓存失效带来的延迟差异，需要的压力数据量级真实要远大于本次测试的4GB，或者需要真实的root权限去直接清空缓存，这两个条件本次实验都没有真实具备。

收尾：真实清理压力数据文件和测试索引

代码真实删除生成的8个压力文件 DELETE /cache_test

分步演示：从purge权限受限的真实约束，到warm基线的1毫秒查询，再到4GB压力下依然不变的真实耗时

每一步都是本文上面在本机真实的Elasticsearch 8.15.0和macOS系统上跑出来的原始结果。

没有root权限清空缓存时，4GB的无关数据压力真实不足以在16GB内存的机器上挤出160MB的热索引数据

这一步新验证的OS缓存压力场景

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 dd/cat 制造内存压力与 vm_stat 系统工具

下一篇 · ELASTICSEARCH 151

磁盘延迟对搜索和写入的影响