Elasticsearch usa 100% de CPU cuando no hace nada

0

Cuando corro top, veo constantemente elasticsearch usando alrededor del 100% de la CPU. He desconectado completamente logstash, y el resultado de marcar "curl localhost: 9200 / _nodes / hot_threads" solo muestra los hilos inactivos:

ubuntu@ip-10-43-108-54:/data$ curl localhost:9200/_nodes/hot_threads ::: {7uyKrAF}{7uyKrAFGS0yMk0XiIrEzUQ}{Bk4GTlkiSqOgNU1cEJVxKw}{10.43.108.54}{10.43.108.54:9300}{ml.machine_memory=16825712640, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true} 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 ::: {7uyKrAF}{7uyKrAFGS0yMk0XiIrEzUQ}{Bk4GTlkiSqOgNU1cEJVxKw}{10.43.108.54}{10.43.108.54:9300}{ml.machine_memory=16825712640, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true} 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 ::: {7uyKrAF}{7uyKrAFGS0yMk0XiIrEzUQ}{Bk4GTlkiSqOgNU1cEJVxKw}{10.43.108.54}{10.43.108.54:9300}{ml.machine_memory=16825712640, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true} 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 ::: {7uyKrAF}{7uyKrAFGS0yMk0XiIrEzUQ}{Bk4GTlkiSqOgNU1cEJVxKw}{10.43.108.54}{10.43.108.54:9300}{ml.machine_memory=16825712640, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true} 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>

¿Cuáles son las causas típicas de esto?

linux elasticsearch usuario79914
fuente

Respuestas:

0

Los hilos que se muestran como Hot son los que Elastic considera hot. Para diagnosticar su condición, querrá ver todos los hilos del proceso para ver si hay actividad inesperada. Para recopilar esta información, siga estos comandos:

ps aux | grep elastic

hogstrom 4675 0.0 3.8 7018056 1284496 s001 S + 4:43 PM 0: 17.49 /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/bin/java -Xms1g -Xmx1g [snip ...]

Luego tome el PID y emita el siguiente comando para obtener un volcado de todos los hilos en la JVM. Usando el ejemplo anterior,

jcmd 4675 Thread.print

Esto le dará un volcado de hilos de todos los hilos de Java. Allí puede ver qué hilos están en la JVM y su estado.

"Elasticsearch [cXcMg1Z] [http_server_worker] [T # 2]" # 61 daemon prio = 5 os_prio = 31 tid = 0x00007fa84fbdd000 nid = 0x14a03 runnable java.lang.Thread.State [0x00007000147fa000]: RUNNABLE en sun.nio.ch.KQueueArrayWrapper .kevent0 (Método nativo) en sun.nio.ch.KQueueArrayWrapper.poll (KQueueArrayWrapper.java:198) en sun.nio.ch.KQueueSelectorImpl.doSelect (KQueueSelectorImpl.java:117) en sun.nio.ch.SelectorImpl.lockA (SelectorImpl.java:86)

El hilo de ejemplo es Runnable. Al revisar todos los subprocesos, debe encontrar un subproceso que se está ejecutando y señalará la tarea que consume CPU.

Hogstrom
fuente
El único subproceso ejecutable que no ejecutaba "epollwait" era un registrador para ml en el xpack, que no uso. Sin embargo, el [WARN ][o.e.m.j.JvmGcMonitorService] [7uyKrAF] [gc][7673] overhead, spent [2.3s] collecting in the last [2.7s]
elasticsearch.log
Parece ser un pico periódico de más de 300% que luego disminuirá.
user79914
¿Puedes aumentar el tamaño de tu montón? ... si estás en GC, entonces no tienes suficiente memoria. ¿Estás ejecutando con -verbose: gc. Eso debería darle una idea de cuánta memoria está utilizando y la relación entre la memoria utilizada y la disponible.
Hogstrom
Cambié el tamaño de almacenamiento dinámico de 1 GB a 10 GB, y todavía está produciendo ciclos de CPU, pero es mucho más estable y responde mejor, ¡gracias!
user79914