Elasticsearch verwendet 100% CPU, wenn nichts unternommen wird

332
user79914

Wenn ich laufe top, sehe ich immer Elasticsearch mit ca. 100% CPU. Ich habe logstash vollständig getrennt und die Ausgabe der Überprüfung von "curl localhost: 9200 / _nodes / hot_threads" zeigt nur im Leerlauf befindliche 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> 

Was sind die typischen Ursachen dafür?

0

1 Antwort auf die Frage

0
Hogstrom

Die Threads, die als Hot angezeigt werden, sind diejenigen, die Elastic für Hot hält. Um Ihren Zustand zu diagnostizieren, sollten Sie alle Threads im Prozess sehen, um festzustellen, ob unerwartete Aktivitäten vorliegen. Um diese Informationen zu sammeln, folgen Sie diesen Befehlen:

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 ...]

Dann holen Sie sich die PID und geben Sie den folgenden Befehl ein, um einen Auszug aller Threads in der JVM zu erhalten. Anhand des obigen Beispiels

jcmd 4675 Thread.print

Dadurch erhalten Sie einen Thread-Dump aller Java-Threads. Dort können Sie sehen, welche Threads sich in der JVM befinden und welchen Status sie haben.

"elasticsearch [cXcMg1Z] [http_server_worker] [T # 2]" # 61 daemon prio = 5 os_prio = 31 tid = 0x00007fa84fbdd000 nid = 0x14a03 lauffähig [0x00007000147fa000] java.lang.Thread.State: RUNNABLE bei .kevent0 (Native Method). bei sun.nio.ch.KQueueArrayWrapper.poll (KQueueArrayWrapper.java:198) bei sun.nio.ch.KQueueSelectorImpl.doSelect (KQueueSelectorImpl.java:117) bei sun.nio.ch.AudioOberel.Java (SelectorImpl.java:86)

Der Beispiel-Thread ist lauffähig. Wenn Sie alle Threads durchgehen, sollten Sie einen Thread finden, der ausgeführt wird, und auf die Aufgabe verweisen, die die CPU verbraucht.

Der einzige ausführbare Thread, der nicht "epollwait" lief, war ein Logger für ml im xpack, den ich nicht verwende. Das elasticsearch.log zeigt eine Menge von Speicherbereinigungsaktivitäten, die auftreten, aber viele Zeilen wie `[WARN] [oemjJvmGcMonitorService] [7uyKrAF] [gc] [7673] gehen auf [2.3s] und sammeln in den letzten [2.7s] ` user79914 vor 5 Jahren 0
Es scheint ein periodischer Anstieg auf 300 +% zu sein, der dann nachlässt. user79914 vor 5 Jahren 0
Können Sie Ihre Heap-Größe vergrößern? Wenn Sie in GC sind, haben Sie nicht genügend Speicher. Laufen Sie mit -verbose: gc. Dies sollte Ihnen eine Vorstellung davon geben, wie viel Speicher Sie verwenden, und welche Beziehung sie zum verfügbaren Speicherplatz haben. Hogstrom vor 5 Jahren 0
Ich habe die Größe des Heap-Speichers von 1 GB auf 10 GB geändert, und die CPU-Zyklen werden immer noch gemustert, aber es ist viel stabiler und reaktionsschneller, danke! user79914 vor 5 Jahren 0