elasticsearch批量索引隨着時間的推移變得越來越慢，具有不變的索引和文檔數量

我遇到了使用.NET NEST客戶端和ElasticSearch的批量索引性能隨着時間的推移而隨着索引和文檔數量的不斷下降。elasticsearch批量索引隨着時間的推移變得越來越慢，具有不變的索引和文檔數量

我們使用Ubuntu Server 12.04.1 LTS 64位和Sun Java 7在m1.large Amazon實例上運行ElasticSearch Version: 0.19.11, JVM: 23.5-b02。除了與Ubuntu安裝配合使用的情況外，此實例上沒有其他任何內容在運行。

亞馬遜M1大實例：從http://aws.amazon.com/ec2/instance-types/

7.5 GiB memory 
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each) 
850 GB instance storage 
64-bit platform 
I/O Performance: High 
EBS-Optimized Available: 500 Mbps 
API name: m1.large

ES_MAX_MEM設置爲4G和ES_MIN_MEM設置爲2克

每天晚上我們的索引/重新索引〜15000個使用NEST文件在我們的.NET應用。在任何給定的時間，只有一個索引< = 15000個文檔。

當第一次安裝服務器時，前幾天索引和搜索速度很快，然後索引開始變得越來越慢。一次批量索引索引100個文檔，過了一段時間，批量操作完成需要15秒。之後，我們開始看到很多以下例外情況，並且索引打磨停止。

System.Net.WebException: The request was aborted: The request was canceled. 
    at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) 
    at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization) :

的builk索引實現看起來像這樣

重新啓動elasticsearch守護進程似乎並沒有做任何任何區別，但刪除索引和重新索引一切一樣。但幾天後，我們會有相同的緩慢索引問題。

我剛剛刪除的指數，後重新啓用刷新間隔的希望，這可能保持從有辱人格的索引中的各散貨指數運行後添加的優化。

... 
... 
finally 
{ 
    EnableRefreshInterval(); 
    elasticClient.Optimize("products"); 
}

我在這裏做了什麼可怕的錯誤？

來源

2012-12-07 Christian Westman

15000應該是微風都爲NEST和Elasticsearch，什麼是幾天後的實際文件數和索引大小？ –

你是如何在ES配置中解決這個問題的？我注意到有一件事絕對需要解決;您已將最大和最小ES堆內存設置爲不同的值。他們應該是一樣的;佔系統可用總內存的50％到60％之間。我目前使用NEST作爲客戶端的回填應用程序每分鐘批量處理100,000個文檔的批量索引，因此15,000應該是微不足道的。你也是一個非常老的ES版本 - 它自19.11以來有了很大的改進（當前爲0.20.4） –

只是冒險猜測：

爲指標性能下降，你會注意索引佔用的磁盤空間更大？

這可能是因爲，而不是重建索引的時候，而不是你加入一些新的文件，有效地加倍文檔數與可能主要與重複數據替換舊索引或舊文件。可能需要抓取陳舊，緩慢的索引並將其加載到某個查看器中進行調試（例如，Luke）。如果您看到的文檔比您期望的要多得多，那麼您可以考慮讓您的重建創建一個新的索引來替換舊的索引。

因爲重新啓動守護進程並不能解決問題，所以我想可以排除打開的文件句柄，正在運行的進程，連接等，儘管我想檢查這些統計信息，並確定是否看到任何懷疑服務器上的行爲。

此外，關於優化，你可能會看到一些性能enhacements它，肯定的，但它是一個非常昂貴的操作。我建議只完全重建後運行的優化完成，而不是每個增量指標批量操作之後。

來源

2012-12-07 10:37:58 femtoRgon

感謝你的指點！我們還沒有真正注意到任何增加的磁盤使用率，也不是CPU的內存。內存通常約爲70％，CPU空閒時間從60％到80％不等。自從我刪除了索引並在批量索引中添加了「優化」後，這已經過去了四天。到目前爲止，我們沒有看到索引降級，希望它能夠保留，但我不確定這個問題是否令人不安。如果情況再次出現，我會研究盧克並挖掘日誌。 –

當然，優化可以解決這個問題是非常合理的。積累大量未經優化的刪除和插入（並且更新只是刪除+插入）肯定會降低搜索性能。在這種情況下，另一件需要注意的可能是您的合併策略，http://www.elasticsearch.org/guide/reference/index-modules/merge.html – femtoRgon

對不起 - 剛開始寫另一相當長的註釋，以爲我只是堅持這一切在一個答案的情況下，它有利於別人......

ES_HEAP_SIZE

我注意到的第一件事這裏是你說你設置elasticsearch的最大和最小堆值爲不同的值。這些應該是一樣的。在配置/ init.d腳本中應該有一個可以設置的EX_HEAP_SIZE。一定要設置（而不是最小值和最大值），因爲它會將最小值和最大值設置爲您想要的相同值。如果你不這樣做的JVM將阻止Java進程，當你開始需要更多的內存 - 在github上的中斷see this great article最近（這裏的報價）：

設置ES_HEAP_SIZE環境變量，從而使JVM對最小和最大內存使用相同的值。將JVM配置爲具有不同的最小值和最大值意味着每次JVM需要額外的內存（最大值）時，它將阻止Java進程分配它。結合舊的Java版本，這解釋了我們的節點在向公開搜索開放時引入更高負載和連續內存分配時出現的暫停。 elasticsearch團隊建議設置50％的系統RAM。

另外檢查出this great post爲更多elasticsearch配置從戰壕。

鎖定內存停止交換

從我的研究，我發現，您還應該鎖定的可用內存量的java程序，以避免內存交換。我不是這個領域的專家，但我所知道的是，這也會導致性能下降。你可以在你的elasticsearch.yml配置文件中找到bootstrap.mlockall。

升級

Elasticsearch還是相當新。由於您所使用的版本（0.19.11）和當前版本（0.20.4）之間引入的錯誤修復非常重要，因此計劃進行相當頻繁的升級。詳情請參閱ES site。您使用的是Java 7，這絕對是正確的選擇，我開始使用Java 6，並且很快意識到它不夠好，特別是對於批量插入。

插件

最後，誰比誰經歷類似的問題，讓安裝用於節點的概述和JVM一個體面的插件。我建議bigdesk - 運行bigdesk，然後用一些批量插入命令彈性搜索，並注意奇怪的堆內存模式，大量的線程等，它都在那裏！

希望有人認爲這有用！

乾杯，詹姆斯

來源

2013-02-05 11:28:56

在專用服務器上，除了設置bootstrap之外。 mlockall = true'，你應該在啓動彈性搜索的daemon .sh腳本中調用'ulimit -l unlimited'。（這樣做可以消除對elasticsearch分配虛擬內存的能力的虛擬限制，這是啓用mlock優化所必需的。）設置ulimits可能非常麻煩，因此我還將一個'ulimit -a'行放入以將值轉儲到日誌中。如果你做得對，運行'top'將在啓動時立即顯示使用大致相同的VIRT和RSS大小的彈性搜索;如果RSS很小，mlockall設置沒有生效。 – mrflip

elasticsearch批量索引隨着時間的推移變得越來越慢，具有不變的索引和文檔數量

回答

相關問題