Elasticsearch использует 100% CPU, когда ничего не делает

525
user79914

Когда я бегу top, я постоянно вижу эластичный поиск, использующий около 100% процессора. Я полностью отключил logstash, и вывод проверки "curl localhost: 9200 / _nodes / hot_threads" показывает только то, что потоки не работают:

ubuntu@ip-10-43-108-54:/data$ curl localhost:9200/_nodes/hot_threads ::: Hot threads at 2018-10-25T18:46:33.827Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:

ubuntu@ip-10-43-108-54:/data$ curl localhost:9200/_nodes/hot_threads ::: Hot threads at 2018-10-25T18:46:35.452Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:

0.0% (101.7micros out of 500ms) cpu usage by thread 'elasticsearch[7uyKrAF][[timer]]' 10/10 snapshots sharing following 2 elements java.lang.Thread.sleep(Native Method) org.elasticsearch.threadpool.ThreadPool$CachedTimeThread.run(ThreadPool.java:543) 

ubuntu@ip-10-43-108-54:/data$ curl localhost:9200/_nodes/hot_threads ::: Hot threads at 2018-10-25T18:46:38.779Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:

ubuntu@ip-10-43-108-54:/data$ curl localhost:9200/_nodes/hot_threads ::: Hot threads at 2018-10-25T18:46:40.579Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:

0.0% (90.5micros out of 500ms) cpu usage by thread 'elasticsearch[7uyKrAF][[timer]]' 10/10 snapshots sharing following 2 elements java.lang.Thread.sleep(Native Method) org.elasticsearch.threadpool.ThreadPool$CachedTimeThread.run(ThreadPool.java:543)  0.0% (33.8micros out of 500ms) cpu usage by thread 'ticker-schedule-trigger-engine' 10/10 snapshots sharing following 2 elements java.lang.Thread.sleep(Native Method) org.elasticsearch.xpack.watcher.trigger.schedule.engine.TickerScheduleTriggerEngine$Ticker.run(TickerScheduleTriggerEngine.java:161)</code> 

Каковы типичные причины этого?

0

1 ответ на вопрос

0
Hogstrom

Потоки, показанные как Горячие, - это те, которые Elastic считает горячими. Для диагностики вашего состояния вы захотите увидеть все потоки в процессе, чтобы увидеть, есть ли активность, которая является неожиданной. Чтобы собрать эту информацию, выполните следующие команды:

ps aux | grep elastic

hogstrom 4675 0,0 3,8 7018056 1284496 s001 S + 16:43 PM 0: 17,49 /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/bin/java -Xms1g -Xmx1g [snip ...]

Затем захватите PID и выполните следующую команду, чтобы получить дамп всех потоков в JVM. Используя пример выше,

jcmd 4675 Thread.print

Это даст вам дамп потока всех потоков Java. Там вы можете увидеть, какие потоки находятся в JVM и их состояние.

"elasticsearch [cXcMg1Z] [http_server_worker] [Т # 2]" # 61 демон PRIO = 5 os_prio = 31 TID = 0x00007fa84fbdd000 NID = 0x14a03 работоспособной java.lang.Thread.State [0x00007000147fa000]: Runnable в sun.nio.ch.KQueueArrayWrapper .kevent0 (собственный метод) в sun.nio.ch.KQueueArrayWrapper.poll (KQueueArrayWrapper.java:198) в sun.nio.ch.KQueueSelectorImpl.doSelect (KQueueSelectorImpl.java:117) в sun.nio.lelectAlector (SelectorImpl.java:86)

Пример потока - Runnable. Пройдя по всем потокам, вы должны найти поток, который работает и укажет на задачу, которая потребляет процессор.

Единственная работающая нить, которая не выполняла "epollwait", была регистратором ml в xpack, который я не использую. Властиasticsearch.log показывают, что происходит много действий по сбору мусора, много строк типа `[WARN] [oemjJvmGcMonitorService] [7uyKrAF] [gc] [7673] накладных расходов, потраченных [2.3s] на сбор за последние [2.7s] ` user79914 6 лет назад 0
Кажется, что это периодический всплеск до 300 +%, который затем уменьшится. user79914 6 лет назад 0
Can you increase your heap size .... if your in GC then you don't have enough memory. Are you running with -verbose:gc. That should give you an idea of how much memory you are using and the relationship to used versus available memory. Hogstrom 6 лет назад 0
Я изменил размер кучи с 1 ГБ до 10 ГБ, и он по-прежнему затягивает циклы ЦП, но он намного стабильнее и отзывчивее, спасибо! user79914 6 лет назад 0

Похожие вопросы