Elasticsearch CPU空閒時高

我對Elasticsearch相當陌生，而且遇到了一些難以解決的問題。我的Elasticsearch（1.1.1）目前正在追加cpu，即使沒有搜索或索引正在進行。 CPU使用率並不總是在100％，但是它有很大的提升並且負載非常高。Elasticsearch CPU空閒時高

以前，這個節點上的索引在沒有任何問題的月份內運行得很好。今天剛剛開始，我不知道是什麼原因造成的。

即使重新啓動ES後，問題仍然存在，我甚至在純粹的絕望中重新啓動服務器。對問題沒有影響。

以下是一些幫助解決問題的統計數據，但我想可能還有更多需要的信息。我只是不確定要提供什麼。

Elasticsearch 1.1.1
的Gentoo Linux 13年3月12日
Java版本「1.6.0_27」
OpenJDK的運行時環境（IcedTea6 1.12.7）（Gentoo的建立1.6.0_27-B27）
OpenJDK的64位服務器VM（構建20.0-B12，混合模式）

一個節點，5個碎片，0副本

上系統

32GB RAM，16GB專用於Elasticsearch
RAM不出現至b這裏的問題。

任何提示解決這個問題，將不勝感激。

編輯：從頂部的信息，如果它是有幫助的。

top - 19:56:56 up 3:22, 2 users, load average: 10.62, 11.15, 9.37 
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie 
%Cpu(s): 98.5 us, 0.6 sy, 0.0 ni, 0.7 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st 
KiB Mem: 32881532 total, 31714120 used, 1167412 free, 187744 buffers 
KiB Swap: 4194300 total,  0 used, 4194300 free, 12615280 cached 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND                     
2531 elastic+ 20 0 0.385t 0.020t 3.388g S 791.9 64.9 706:00.21 java

來源

2014-04-30 Sgt B

你可以給我們更多的細節，如你的htop日誌？ – eliasah

添加頂部信息（沒有安裝htop）。讓我知道你還有什麼想看的東西。 –

Lucene做了一些我知道的背景合併。我會看看CPU高電平時是否可以進行線程轉儲，也許你可以看到可能會佔用CPU。否則，我會發布到ES組。 – Andy

正如Andy Pryor所說，後臺合併可能是導致問題的原因。我們的指數翻轉已經暫停，我們目前的兩個指數超過200GB。滾動他們似乎已經解決了這個問題，我們一直在哼着歌。

編輯：當看似空閒時的高負荷被確定是由幾個非常大的指數合併引起的，這些指數並沒有每週滾動。這是內部流程每週都要推出索引的失敗。在解決這個問題後，合併時間縮短，高負荷消退。

來源

2014-05-01 19:49:03

這不是一個答案！它看起來更像是@Andy Prior寫過 – eliasah

的澄清答案。 –

Elasticsearch CPU空閒時高

回答

相關問題