前言
对于广大 Elasticsearch 使用者而言,在面对系统资源分配、问题请求排查时是否曾遇到以下问题:
- 只知道需要预留许多内存资源给 lucene(一般为系统资源的一半),但是分配的这些是否够用,以及这些内存资源被什么文件所占用,往往都不得而知;
- 线上服务突然出现一波超时告警,告警波及的索引面积较广,但波动具体由哪个索引,甚至哪个查询导致的,在排查时容易陷入无从下手的困境。
通常在 Elasticsearch 的监控层面,我们会选择去查看 kibana 的监控报表,但 kibana 在内存方面的监控指标通常都基于 JVM 本身,无法追溯到 lucene 层面。而 lucene 的文件使用的是操作系统的 page cache,如何监控 page cache,并将之映射到 Elasticsearch 的索引维度,便是本文着手解决的问题。
接下来本文将分为三个主要部分,第一部分介绍和 Elasticsearch 内存使用相关的基础知识,适合对 ES 内存资源占用有兴趣的同学,第二部分介绍 Elasticsearch 的 page cache 监控工具和使用说明,第三部分列举一些典型的使用案例。
基础知识
对搜索引擎而言,各级缓存的命中率和查询效率密切相关。ES 的缓存主要由 JVM 堆内存,以及 lucene 所依赖的堆外内存两部分组成。考虑到大多数查询场景的多样性,ES 的 query cache 覆盖能力有限,因此 ES 的查询性能和 lucene 各类文件的缓存状况息息相关,能否通过 page cache 尽量减少查询过程中产生的文件IO 将直接影响到查询效率。本节将从 Elasticsearch 内存分布,lucene 文件类型和使用场景,文件读取方式几个层面展开介绍。
Elasticsearch 内存相关
ES 进程的 JVM 堆内存主要包括以下几部分内容(不详细展开)
- Indexing Buffer:索引缓冲区,用于存储新索引的文档,当其达到阈值时,会触发 ES flush 将段落到磁盘上;
- Fielddata:用于 text 字段分词或排序时获取字段值,基于 lucene 的 segment 构建,伴随 segment 生命周期常驻在堆内存中。
- Node Query Cache:负责缓存 filter 查询结果,基于 lucene 的 segment 构建,缓存在堆内存中,ES 节点默认的 cache 大小为堆内存的10%,采用LRU机制。
- Shard Request Cache:针对 ES 的 query 请求,缓存各分片的查询结果,主要用于缓存聚合结果,采用LRU机制,当分片 refresh 后会失效。
对于 lucene 而言,其使用的是堆外内存
- Page Cache:lucene 读写段文件时会依赖操作系统的 page cache 缓存,如果多次查询都涉及到读取某个段文件的同一部分内容,就直接使用 page cache 进行读取,无需再从磁盘获取数据。page cahce 由操作系统管理,淘汰策略类似LRU。
lucene 文件类型
ES 的一个分片就是一个 lucene 实例,实例由一个或多个 segment 构成。lucene 每次 flush 操作都会对一个 segment 进行持久化操作(会将内存中的 segment 写到文件,但不执行 FileChannel::force,即存在数据丢失的可能),其内容为期间有变更的文档,同一个段涉及到的文件前缀都是相同的 generation(36进制的一个数字,每次 flush 会加一),每个段可能涉及到的文件如下表所示。
文件后缀 |
存放信息 |
关联 ES 的查询场景 |
.tip |
词典的fst,以及到.tim的索引 |
term查询、全文搜索等场景 |
.tim |
存放term info以及指向.doc、.pos、.pay的指针 |
|
.doc |
倒排表及词频 |
|
.pos |
记录term的位置信息 |
match_pharse等需要位置信息的查询 |
.pay |
payload信息 |
|
.fdt |
存放原始文档,正向存储 |
获取source等字段值 |
.fdx |
fdt的索引 |
|
.dvd |
DocValues 列式存储 |
聚合、排序、脚本等场景 数值类型的range查询 |
.dvm |
.dvd的索引 |
|
.nvd |
Norms data |
全文搜索的tfNorms计算 |
.nvm |
.nvd的索引 |
|
.dim |
数值类型的索引,BKD树结构 |
数值类型的range查询 |
.dii |
.dim的索引 |
|
.liv |
记录被删除的文档号 |
|
.cfs |
复合文件 |
新写入数据生成的段文件,引入该文件主要用于减少文件句柄数 |
.cfe |
复合文件,.cfs的索引 |
|
.si |
记录段的元信息 |
lucene 文件功能说明备注
- tip 和 fdx 类型的文件在 ES 7.3 以前都是常驻 JVM 堆内存的,ES 7.3 之后将 fst 移至堆外,交由系统的 page cache 管理,若某个索引的 fst cache 不幸被置换出去,理论上会给搜索带来较大的抖动,对于使用 7.x 版本的用户,建议多关注 tip 文件的 cache 情况;
- 上述文件中占用存储空间较多的是 tim、doc、fdt、dvd 以及 cfs 这几类数据文件,除 cfs 以外的几类文件加载情况和查询条件密切相关;
- range 查询即可能使用 dim BKD 索引,也可能使用 dvd DocValue,其背后是一个基于代价的优化器处理逻辑 ,如有兴趣,细节逻辑可自行参考 IndexOrDocValuesQuery。
lucene 文件读取方式
lucene 文件的读取方式将影响磁盘 IO 调用,以及 page cache 中缓存的内容,常用的主要是如下两种类型:
- niofs:通过 NIO 的方式读取文件内容,基于 Java 提供的 FileChannel::read 方法读取数据,支持多线程读取同一个文件,按需读取,需要注意的是 niofs 模式下读取到的内容在系统层面也会进 page cache。
- mmapfs:通过mmap读写文件,会比常规文件读写方式减少一次内存拷贝的过程,因此对于命中 page cache 的文件读取会非常快,该模式即零拷贝的一种实现(可减少内核态和用户态间的数据拷贝)。不过 mmap 系统调用在内核层面会产生预读,对于 .fdt 这类文件,预读读到的内容后续命中的概率极低,还容易引起page cache的争用,进而产生频繁的缺页中断,相关问题可参考https://github.com/elastic/elasticsearch/issues/27748
ES 支持通过 index.store.type 设定文件加载方式
- ES 6.*版本默认为 mmapfs
- ES 7.0开始默认为 hybridfs,该模式下每类文件会选择最优的读取方式,例如 .doc 由于倒排表的缓存命中率较高,被设定为 mmapfs,而 .fdt 只在获取 _source 时使用,访问较为稀疏,被设定为 niofs。
工具使用说明
综上所述,lucene 各类文件占用 page cache 的情况将极大的影响 Elasticsearch 的查询效率,如何系统的监控各类文件在 page cache 中的占用,以及换入换出的波动,将为 ES 的资源分析和性能监控提供一种新的角度。
如果想采集系统的 page cache,可以借助 pcstat、vmtouch 等工具,其实现原理均是通过 mincore(2) 系统调用,mincore能确定一块虚拟内存区域中的分页是否驻留在物理内存中。其中 pcstat 是款基于Go的开源工具(https://github.com/tobert/pcstat),开发初衷是用于监控 Cassandra 中 ssTables 的占用情况。
本工具 es-pcstat基于 pcstat 进行二次开发,以 ES 索引为维度,细化到 lucene 文件的粒度来对 page cache 占用情况进行采集,可对cfs、fdt、doc、pos、tim、dvd等重要文件进行细粒度的采集和监控。支持数据输出到控制台、日志、ES,配套kibana仪表盘支持查看各索引、各类文件的时序变化曲线。
源码地址
https://github.com/zhangdapao995/es-pcstat
功能点
采集目标:ES索引下各类 lucene 文件的 page cache 占用,单位MB,默认采集全部索引,支持配置采集的索引前缀。
运行环境
- 系统环境: 类unix、linux环境
- ES 版本:6.x、7.x
功能项
- 数据输出:控制台、日志和ES
- 控制台:查看各索引 cache,支持排序
- 日志和ES:采集维度从上到下依次为 节点->索引->主副分片->文件后缀
- 可视化:数据输出为 ES 时,支持 kibana 仪表盘配置
- 支持按节点、索引、主副分片类型筛选查看
- 支持查看索引 page cache top10 波动曲线
获取可执行文件
linux_x64
linux 64位可通过如下命令获取可执行文件
curl -L -o es-pcstat https://gitee.com/verdant/es-pcstat/attach_files/835465/download/es-pcstat-linux-x64 chmod 755 es-pcstat
mac
mac 64位可通过如下命令获取可执行文件
curl -L -o es-pcstat https://gitee.com/verdant/es-pcstat/attach_files/835463/download/es-pcstat-darwin-x64 chmod 755 es-pcstat
运行
执行命令
./es-pcstat [parameters] <config_file> 例:./es-pcstat -collectIntervalFlag=30 -sortFlag=true ./es.conf
运行可选参数
-collectIntervalFlag int 采集间隔 (default 60) -outputTypeFlag string 数据输出方式 [es, log, console] (default "console") -sortFlag 仅对console类型生效,结果按page cache大小排序
配置文件
配置文件需填写ES ip、端口、节点名、集群名和数据目录,其中path需要填写indices目录,一般为 ES 的 data.path 配置后增加"/nodes/0/indices"。
名称 |
描述 |
默认值 |
es.ip |
采集的es节点ip |
|
es.port |
采集的es节点端口 |
|
es.indicesPath |
采集的es节点indices目录,一般为"${data.path}/nodes/0/indices" |
|
es.nodeName |
采集的es节点名 |
|
es.clusterName |
采集的es集群名 |
|
es.collection.indicesPrefix |
需采集的索引名前缀,不填则采集全部;样例:pcstat |
|
output.log.keepLogNum |
针对日志形式输出生效,保留日志文件个数(按天拆分) |
5 |
output.log.logPath |
针对日志形式输出生效,日志全路径 |
/tmp/pcstat.log |
output.es.keepIndexNum |
针对es输出生效,保留索引个数(按天拆分) |
5 |
output.es.pcIndexName |
针对es输出生效,索引名(如需使用kibana仪表盘配置请勿修改) |
pc_stat |
#es confes.ip=127.0.0.1es.port=9200es.indicesPath=/xxx/xxx/elasticsearch-6.7.1/data/nodes/0/indiceses.nodeName=node1es.clusterName=es_local#采集索引前缀,设置为空则采集全部es.collection.indicesPrefix=#该配置仅日志输出生效 output log,保留个数单位为天output.log.keepLogNum=5output.log.logPath=/tmp/pcstat.log#该配置仅es输出生效 output es,保留个数单位为天output.es.keepIndexNum=5output.es.pcIndexName=pc_stat
输出模式
控制台输出
执行命令
./es-pcstat -collectIntervalFlag=30 -sortFlag=true ./es.conf
结果示例
|index_name|cache (MB) |pricache|repcache|+---------------------------------------+------------+------------+------------+|fusion-media.task.task|247|247|0||total|247|247|0|+---------------------------------------+------------+------------+------------+
日志输出
执行命令
./es-pcstat -outputTypeFlag=log ./es.conf
对应日志文件得到的内容,日志可进一步通过日志服务采集分析(如阿里云sls等)
{"cache":{"cfs":0,"dim":0,"doc":0,"dvd":0,"fdt":0,"nvd":0,"other":0,"pos":0,"tim":0,"total":0},"cluster_name":"es_local","fields.time":"2021-05-06T15:16:30.525475+08:00","index_name":"total","level":"info","msg":"","node_name":"node1","primary":false,"time":"2021-05-06T15:16:30"}
ES 输出
执行命令
./es-pcstat -outputTypeFlag=es ./es.conf
运行后会将采集到的数据回写到被监控的 ES 集群
可导入kibana仪表盘配置文件📎es-pcstat-kibana.json,通过图表进行page cache分析。
导入方式
图1 kibana导入仪表盘配置
导入后打开dashboards菜单栏,page_cache仪表盘
图2 kibana仪表盘入口
细节可查看如下图表
1)cache占用top10的索引波动图
图3 kibana仪表盘-cache top10
2)cache详细信息,可筛选节点、索引、主副分片,不选择展示合计数据。
图4 kibana仪表盘-cache占用详情
备注
- 如需使用上述kibana仪表盘导入文件,请勿修改conf文件中的output.es.pcIndexName以及运行命令的collectIntervalFlag,修改output.es.pcIndexName会导致仪表盘读不到数据,修改collectIntervalFlag会导致仪表盘聚合数据异常;
- kibana7.5后Date Histogram的interval有所调整,会导致时间拉长后interval成倍增大,统计值不准,建议选取时间范围在4-6小时内,问题见https://elasticsearch.cn/question/11062
使用案例
通过 es-pcstat 采集得到的 page cache 时序图,可为性能监控、资源分析、异常请求定位等问题提供一定帮助,以下将从笔者团队使用中的几个案例进行展开。
一个简单示例:每条横线代表一个索引的所有 lucene 文件资源占用,一小时内的采样可以发现两个转折点
- 1 触发了副本清0操作,由于该集群副本不涉及搜索,所占用的内存比例较少
- 2 触发了一些查询请求,部分索引所占资源上涨
图5 索引资源波动-基于阿里云sls仪表盘
案例一:资源分析
通过观察一段时间的资源波动可评估预留给 lucene 的 page cache 是否充裕,如下两张图展示了两个集群中单个节点一天的资源占用情况,图6资源较为充裕,整体趋势几乎无大的波动,图7资源较为紧张,频繁出现 page cache 的换入换出。
图6 索引内存资源评估-充足
图7 索引内存资源评估-不足
案例二:merge的影响
如图8所示,通过监控可以发现某个索引的 page cache 上涨非常明显,导致其他索引的资源被换出,这种抢占会导致搜索服务波动;通过kibana排查该时间段内该索引的监控,发现段的数量有所下降,查看段文件后发现在该时间段后生成了几个较大的段文件,判定是 merge 导致 page cache 上涨,通过图9可以看到 merge 过程中 fdt 文件的上涨尤其明显(主要因为 merge 需要 load 原始内容进行处理),merge 完成后 fdt 的 cache 会慢慢的换出。
由于采用了存储计算分离的架构,后续可考虑将数据规模达到一定阈值的 merge 操作移到专属的 merge 节点处理,以此减少 merge 引起的 cache 换入换出对搜索服务节点带来的波动。
图8 整体资源波动,某个索引资源迅速上涨
图9 引起问题的索引波动,fdt上涨尤为明显
案例三:异常查询请求定位
有时集群的整体响应突然变慢,却不知道是由哪个索引、或哪个查询引起的?
例如某天一个 ES 集群突然出现大量超时请求,查看节点监控,ygc有所下降,cpu利用率一直在高位;再查看磁盘监控,发现磁盘读吞吐处于高负荷状态。
图10 异常请求引起的磁盘IO满负荷
通过这些常规的监控无法进一步定位到异常原因,再来看看 page cache 的监控。根据“索引cache top N”图表可以明显发现异常时间点有个索引的cache大幅度上涨,其他索引的 cache 都有所下降,在异常时间段内,曲线的毛刺极为明显,由此可以判断是堆外内存不够,导致各索引的 page cache 出现争用,进而需要从磁盘上获取数据。
图11 索引内存资源占用波动-top10
再进一步查看 cache 上涨期间问题索引各类文件的 cache 情况,可看到 doc和pos 有明显上涨,doc文件存储倒排表及词频,由包含每个 term 以及频率的 docs 列表组成,pos 存储出现在索引中 term 的位置信息。二者在 phrase 查询中会被联合使用。当一个平时使用率不高的索引突然出现了大量的 phrase 查询,内存资源比较吃紧(该节点预留给堆外的只有7 GB),进而就产生了上述问题。
图12 索引内存资源占用波动-异常索引详情
对于某些突发的,却给集群造成较大压力的请求,可以尝试通过 page cache 监控去排查定位。
当然要把具体的 lucene 文件类型变化趋势和查询关联起来,需要对各类查询涉及的文件有一定了解,相关细节可查看“基础知识->lucene 文件类型”一节,典型的如
- dvd 上涨可以猜测是有聚合、脚本、排序的请求
- doc、pos上涨可以联想到是否有 phrase 查询请求
- fdt 上涨可能涉及大量的源数据拉取或 merge 操作
案例四:为性能优化制定方向
随着系统的发展、数据量的增长,在某个业务场景 ES 相关的资源和效率可能逐渐成为瓶颈,这时候我们就需要从底层视角来推动上层的优化,如图13所示,根据监控曲线可发现 fdt、doc、pos 几类文件的常驻内存资源较多,便可从这3类文件的使用情况出发来制定优化方向:
- fdt 常用于获取_source字段的内容,如果存储并在查询结果中获取大量字段很容易导致该文件频繁访问,进而占用较多资源,可以考虑对 _source 进行适当删减,或将数据获取逻辑移至宽表数据库,如HBase等,让 ES 的资源更多的用于搜索本身;
- doc 在 term 和全文搜索场景均有使用,这类文件的加载通常不可避免,可以从降低文件大小来入手,如在分词层面进行优化,对词的分布进行统计分析,来评估是否可以补充停用词等;
- pos 用于需要位置信息的 phrase 查询,可从查询语句的拼装进行优化。
图13 观察内存资源占用来制定优化方向
总结及未来展望
es-pcstat 从 ES 索引和 lucene 各类文件 page cache 占用的角度,提供了一种对 ES 进行监控的全新思路,基于这些监控数据我们可以进行资源的饱和度评估,异常查询请求的定位,或者为性能优化制定方向。
当然异常请求的定位都只能限于事后分析,无法避免问题的产生,如何通过监控数据和查询请求去评估一个 query 可能对集群产生的影响,并拦截可能导致较大 page cache 争用的请求,这将能为集群的稳定性提供更大的保障。
es-pcstat 采集细化到了 lucene 文件的粒度,需要具备一定基础知识和经验才能快速定位背后原因,因此在分析上具备一定门槛,如果能根据文件波动来为监控者提供一些 ES 层面的提示,将能服务更广大的 ES 用户。
在 ES 中对一个查询的成本(涉及JVM中的缓存、系统内存缺页中断、IO、CPU等)进行评估本身是一件比较难的事,page cache 的监控可能能提供一定的帮助,当然还有更多的作用等待我们去探索。
参考链接
https://github.com/tobert/pcstat
https://www.amazingkoala.com.cn/Lucene/2019/1205/115.html
https://www.elastic.co/guide/en/elasticsearch/reference/master/index-modules-store.html