我会先确认影响范围，同时控制故障继续放大。从慢查询、写入抖动、分片、堆内存和集群负载系统排查 Elasticsearch 性能问题。Elasticsearch 性能问题通常来自查询扫描范围过大、高基数聚合、深分页、Mapping 不合理、分片过多或倾斜、写入批次不当、频繁 Refresh、Segment Merge 压力和 JVM 堆内存不足。处理时应先止损并保存现场，再根据搜索、写入、存储和集群指标定位瓶颈，不能只靠增加节点或扩大内存。

止损之后，我会按请求链路建立证据，而不是凭经验猜。 nodes/hotthreads/tasks：CPU 与运行任务。 profile API/slowlog：算子与慢查询证据。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

定位时我最关注这些参数、指标和容量关系。同一查询在单次与混合并发下采集 read docs、heap、拒绝和 query/fetch。

找到根因后先做最小修复，再用同样的流量验证。新节点让每个索引拥有更多小分片，请求扇出和协调成本上升，缓存也更分散。合并小索引、调整分片布局并限制高基数聚合后，性能才改善。 只看 CPU 忽略协调和队列：query/fetch 分阶段耗时：先减少扫描和扇出。 Profile 每个线上重查询造成额外压力：线程池队列与拒绝：Profile 仅受控样本。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「read docs/result」为主基线，记录值应满足「记录稳态基线」；同时保存 query/fetch 分阶段耗时、线程池队列与拒绝，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。性能排查应先定位“时间和资源花在哪个阶段”，再选择索引、查询、分片或容量动作；节点多并不自动更快。