CPU 才用一半,搜索却卡成 PPT:Elasticsearch 慢起来,先别急着加机器

搜索变慢了，你打开监控：CPU 不高，堆内存也没顶满。

“机器还有余量，线程再开多一点？”

如果瓶颈在磁盘，这个动作可能让请求排得更长。另一种常见操作是重启：页面暂时恢复了，可故障线索也断了，分片恢复和缓存重新变热又带来新一轮负担。

Elasticsearch 排障最容易浪费时间的一步，是还没确定谁在忙，就开始改参数。

这篇按现场排查顺序，把磁盘 IO 这条线拆开。示例是排障方法，不是某次生产事故实录。

第一眼先分清：磁盘“满”是哪种满

容量用了 95%，和 iostat 里的 %util 接近 100%，不是一个问题。

前者涉及空间、水位和分片分配；后者表示设备忙碌时间，但在 SSD、RAID 及云盘场景，单看它也不能断言性能已经到顶。

先采几组连续数据：

-y 跳过从开机以来累计的首份报告。重点把读写吞吐、r_await/w_await 和 aqu-sz 放一起看，再对照云盘的 IOPS、吞吐上限及突发额度。字段名会随 sysstat 版本变化。

等待时间和队列一起涨、业务延迟也在涨，才值得沿这条线继续查。disk.used_percent 只能告诉你容量，不能代替 IO 延迟。

第二眼，找出谁在和搜索抢磁盘

读写、段合并和恢复可能同时争用存储资源。

在 Kibana Dev Tools 里，可以先执行这些只读查询。示例面向自管理集群，托管服务和不同版本的接口权限可能不同。

GET _nodes/stats/fs,indices,jvm,thread_poolGET _cat/recovery?v&active_only=trueGET _cat/shards?v&h=index,shard,prirep,state,node

第一条不要只保存一张截图。隔一段固定时间再取一次，比较 indices.merges、refresh、indexing、search 等累计计数的变化；节点重启后计数会重置，不能跨重启直接做差。

接着判断更像哪种情况：

这些是排查方向，不是看到一个指标就能盖章的根因。

一个容易反直觉的原因：你的磁盘在“整理文件”

Elasticsearch 底层的 Lucene 索引由 segment 组成。segment 不可变，新写入不断形成新段，后台再把小段合成大段，顺带清理部分删除记录。

这个过程要读旧段、写新段，还需要临时空间。查询、写入和合并同时发生，就会争抢同一块存储。

频繁刷新、持续更新和过碎的写入，都值得一起检查。但 refresh 不等于 fsync，也不等于数据已经持久化到磁盘，不能把刷新次数直接当作落盘次数。

如果业务允许新数据稍晚一点被搜到，可以针对写入索引评估增大 refresh_interval。代价也很明确：可搜索的新鲜度会下降。先记录原值、小范围观察，再决定是否保留。

两个“优化”，很容易把现场搞得更糟

一是看到段多，就对活跃索引执行 force merge。

Elastic 明确建议主要对只读索引做强制合并。它会消耗大量资源；合并为单段时，空闲空间需求还可能达到分片大小的三倍。正在持续写入的索引，不适合拿它当一键加速按钮。

二是把空余内存都给 JVM。

搜索还依赖操作系统的文件系统缓存。堆变大了，留给缓存的空间却少了，原本能从内存读取的数据可能更多地走磁盘。Elastic 的性能指南明确强调给文件系统缓存留足内存。

CPU 没跑满，不代表系统有能力再接更多请求；JVM 没用满，也不代表多分一点堆就会快。

最后再决定，是限流、改查询，还是升级磁盘

如果是一次异常批任务把写入压上来，先限制这批任务；如果是某类查询扫得太宽，先处理它的时间范围、排序、聚合和返回字段；如果是恢复碰上高峰，先评估恢复任务与前台请求的资源分配。

只有确认日常负载就长期逼近存储能力，增加 IOPS、换盘或扩容才是有依据的选择。

保存故障时段的三样东西：设备指标、ES 内部统计、发布与任务时间线。 下次再慢，能对上这三条线，比记住十个“万能调优参数”有用。

需要补索引、分片和读写流程，可以查看云栈《Elasticsearch 实战：从入门到集群优化》：https://yunpan.plus/t/84。先读目录里的读写流程、路由与分片章节；课程版本较早，命令和参数对照你正在运行的 ES 版本使用，获取价格以页面算力提示为准。

资料依据：Elastic 官方索引性能、搜索性能、Merge settings 及 Force merge API 文档。