Elasticsearch 7.3.2总查询耗时远高于单分片耗时如何排查

根因前置判断 #

你描述的三个特征可以直接排除查询执行逻辑本身的问题：仅长期未访问的冷数据首次请求触发、停止写入后异常自动消失、profile统计的单分片执行耗时仅数百微秒但总took超1s。这类耗时全部来自profile统计范围外的前置环节，和查询语句本身的执行效率无关。

排查步骤 #

• 第一优先级验证操作系统页缓存缺失问题
  冷数据长期无访问时，索引对应段文件会被操作系统从页缓存中换出，首次查询需要从磁盘加载倒排索引、doc value、元数据到内存，这部分磁盘IO耗时不会被profile计入分片执行时间。验证方式：异常复现时用iostat观测数据盘指标，如果首次查询时磁盘读IO突增、iowait占比升高，同条件二次查询时磁盘读几乎降为0，即可确认。停写后索引不再生成新段、也没有写入带来的缓存换出，数据加载进缓存后不会再触发磁盘读，和你观察到的停写后异常消失的特征完全吻合。
• 排查写入触发的资源等待耗时
  7.3版本中查询执行前需要获取分片读锁，如果请求时点正赶上大段合并、refresh、translog刷盘，会产生锁等待耗时，这部分时间同样不会被profile统计。验证方式：异常复现时调用 GET _nodes/stats/indices/indexing,refresh,merge,translog?filter_path=nodes.*.indices 查看对应节点的运行指标，确认首次查询时间点是否存在运行中的大段合并任务、refresh频率是否过高、translog刷盘是否存在积压。
• 验证写入流量对页缓存的挤占
  持续实时写入时，写入请求会优先占用操作系统页缓存，把冷索引的段数据挤出缓存，哪怕冷数据之前被加载过，写入流量足够大时还是会被反复换出，这也是停写后异常消失的核心诱因之一。可以用vmtouch扫描目标索引目录的文件缓存占比，对比写入高峰、停写两个状态下的缓存命中率差异即可确认。

解决方向 #

• 解决冷启动页缓存缺失问题
  • 配置索引预热任务，定时发起轻量的轮询请求访问冷分片，触发核心索引文件提前加载到页缓存，避免用户首次请求触发磁盘读
  • 根据业务实时性要求调大index.refresh_interval参数，不要使用默认1s配置，实时场景可调整为30s~60s，降低新段生成频率，减少段碎片化的同时降低写入对页缓存的挤占
  • 若冷数据访问频率极低无法接受预热资源开销，可将存储介质更换为更高性能的SSD，降低随机读延迟
• 解决写入带来的阻塞与缓存挤占问题
  • 调整段合并策略，将index.merge.policy.max_merged_segment设置为匹配硬件性能的阈值，避免超大段合并长时间占用IO、锁资源阻塞查询
  • 做写入流量限流，预留至少30%的节点内存、IO带宽给查询链路，避免写入打满资源挤占冷数据缓存
  • 落地冷热节点分离架构，将长期无访问的冷索引迁移到不承接实时写入的冷节点，从根源上隔离写入对冷数据查询的影响
• 后续慢查询排查优化
  不要仅依赖profile结果定位耗时，请求卡顿时调用GET _nodes/hot_threads抓取线程栈，可以直接定位到锁等待、磁盘IO等profile覆盖不到的阻塞点，排查效率更高。

内容的提问来源于stack exchange，提问作者Rukang Zhu