单节点ES OSS 7.0运行时突然卡顿无响应、请求被拒绝如何排查

第一步：优先排查Windows环境特殊问题 #

• 临时关闭杀毒软件的实时防护、文件扫描、网络扫描功能，观察72小时是否复现故障：大量Windows上部署ES的故障案例中，杀毒软件会对ES的lucene索引文件、网络端口通信做静默扫描/拦截，无明显CPU/IO占用上报但会阻塞ES内部线程执行
• 检查Windows虚拟内存（分页文件）配置：确认是否开启了自动管理分页文件，ES运行时若触发系统页交换，即便物理内存空闲也会导致线程阻塞，建议关闭分页文件或固定分页文件大小为物理内存的1-2倍
• 检查ES进程的Windows权限：确认ES运行账户对ES安装目录、数据目录有完全控制权限，避免权限校验导致的文件操作阻塞

第二步：ES JVM层面排查 #

• 调整GC日志输出参数：在jvm.options中添加以下参数，开启详细GC日志输出，故障发生后查看是否有Full GC长时间停顿、元数据区溢出问题

-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationStoppedTime
-Xloggc:gc.log

• 检查堆内存配置：3GB总数据量下4GB堆内存配置合理，但若存在大量聚合查询、字段缓存未释放问题，仍可能导致堆内存碎片过多，可临时将Xmx调整为8GB观察故障是否复现
• 故障发生时强制导出JVM堆转储：使用jmap -dump:format=b,file=es.hprof <ES进程ID>命令导出堆内存快照，后续用MAT工具分析是否存在内存泄漏、大对象占用问题

第三步：ES内部逻辑排查 #

• 检查是否配置了Ingest Pipeline：从报错日志看是写入线程池满导致的请求拒绝，且报错关联IngestService，若有自定义Ingest Pipeline，先临时关闭所有Pipeline，直接写入原始数据观察是否复现
• 调整写入线程池配置：单节点16核默认写入线程池大小为16、队列200是默认配置，若有批量写入大小超过1MB/次的情况，可适当调大队列到1000，同时限制单批写入数据量不超过5MB
• 关闭非必要的集群定时任务：确认磁盘空间充足的前提下，在elasticsearch.yml中添加以下配置，关闭磁盘水位线自动检测，避免定期任务阻塞

cluster.routing.allocation.disk.threshold_enabled: false

第四步：故障现场采集优化 #

下次故障发生时不要立即重启，按以下顺序采集信息：

• 使用jstack <ES进程ID> > jstack.log命令导出3次线程栈，间隔10秒一次，分析是否有线程死锁、大量线程阻塞在文件读写/锁等待的情况
• 执行curl http://localhost:9200/_cat/pending_tasks?v查看集群挂起任务，确认是否有长期未执行的集群级任务阻塞
• 执行curl http://localhost:9200/_nodes/stats/thread_pool?v查看所有线程池的运行状态，确认是否有除写入线程外其他线程池满的情况

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