elasticsearch-运维-文件缓存

Posted 2023-03-17

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了elasticsearch-运维-文件缓存相关的知识，希望对你有一定的参考价值。

参考技术A 服务器上部署了ES5集群，通过zabbix监控发现cpu load呈锯齿状，且ES所在磁盘iops read和cpu load有一样的锯齿，可证明ES周期性的发生大量读磁盘操作。通过分析，ES周期性大量读磁盘是因为QA每10分钟发起搜索业务请求
此外，该机器上有marathon超卖内存的情况存在，当关闭超卖的服务时，iops read及cpu load监控正常

按理说QA监控发起的搜索请求不会变化，ES应该有索引文件缓存。所以首先分析ES索引文件缓存的情况
通过/proc/$pid/smaps可查看进程内存分布及映射情况，如下图所示，size表示通过mmap映射的文件的大小，Rss表示该文件mmap实际内存的大小，Pss表示当某个文件被多个进程同时使用时，平均每个进程占用的内存大小

写个脚本，分析一下文件缓存使用情况：

索引5s96iIBfS6KivdgDrb8u-Q映射文件大小为44.3g，实际占用物理内存838M，对比其他服务器同索引文件缓存使用情况发现，大于该机器占用的物理内存（2.1g 对比 838M）
通过监控ES进程的smaps文件发现当cpu飙升即搜索请求时，文件缓存占用高达2-3G，请求完成一段时间后文件缓存将至700-800M，此时可判定是因为文件缓存被系统踢掉导致频繁发生磁盘io
通过分析源码可知ES使用MMapDirectory打开索引文件，其内部FileProvider调用C库的mmap函数打开文件，所以是由系统托管文件缓存
为何操作系统会踢掉ES文件缓存？猜测是因为marathon超卖导致内存使用过多，操作系统需要回收文件缓存，而QA监控又是10分钟请求一次，导致ES无法持有文件缓存

通过调整操作系统内核参数vm.vfs_cache_pressure(100 => 80)来让操作系统尽量少回收文件缓存，调整后相关监控如下

ES节点内存维持较之前提升至少500M

通过监控分析smaps文件能获取各索引文件物理内存占用情况，发生堆外内存异常时可排查是哪些索引文件导致的，即可大致推断是什么业务什么类型的查询
heap内存可以使用jhat、jmap分析使用情况
匿名页缓存可在jvm启动参数加上-XX:NativeMemoryTracking=[off|summary|detail]后，通过jcmd $pid VM.native_memory detail分析