Elasticsearch 填坑記

wishma發表於2018-06-23

前言

        技術的發展日新月異,傳統企業資料庫Oracle、SqlServer、DB2,Mysql等在今日不斷的被各種大廠自研資料庫取代,當然也有類似Elasticsearch等優秀的滿足海量資料所使用的開源資料庫。

       我司多個日誌審計與態勢感知專案中,也沒有免俗,選擇了Elasticsearch作為我們的日誌儲存與搜尋引擎。關於Elasticsearch基礎知識就不做更多介紹了,隨便搜尋下,有大量的介紹和使用文件。

       本文主要介紹我們在多個專案中,使用Elasticsearch過程中,各種填坑記錄。

       在具體的生產環境中,我相信大家不會用Windows作為Elasticsearch的執行伺服器的,所以下文基本都是以Linux(Centos7)為主要的執行環境。

       以下內容,僅供參考,實際遇到的問題,都需要在運維過程中,去仔細分析,查閱文件。解決問題的方法可能很簡單,關鍵是能準確的定位問題,分析問題。

  • 安裝

       Elasticsearch安裝就不多闡述了,主要記住:建立非root使用者,修改linux系統引數,修改jvm執行引數,修改Elasticsearch執行引數,這4個主要部分。

       由於Elasticsearch版本迭代比較快,不同的版本個別引數可能已經變更或廢棄,所以修改前一定要認真閱讀對應版本的官方文件,該引數是否還有效,這個地方是一個坑,需要重點注意。

 

  • 執行與系統調優

       Elasticsearch的安裝其實還是比較簡單的,但是在實際執行中,各種各樣的問題就來了。在實際執行中出現的問題,其實主要還是資料量的問題,隨著資料量的增長,就會出現各種資源問題,需要隨時解決和調優。

1.記憶體問題

       官方建議Elasticsearch每個節點jvm配置記憶體不要大於系統總記憶體的一半同時不要大於32G。

       Elasticsearch本身在執行過程中,隨著資料量的增加,記憶體的使用會越來越多,gc回收會越來越慢,最終導致Elasticsearch雖然活著,但不響應任何請求。

       這種情況下,擴充節點是個選項,但是大多數的情況,預算是固定的,硬體資源也是固定的,只能採取其他辦法。

  • 資料要根據業務做成多索引的方式,因為每個索引都是佔用記憶體的,多索引才有可能關閉部分歷史資料索引,釋放記憶體。最好做成定時任務,按照規則關閉不用的索引。

  • 定時對索引進行合併(merge segment)

  • jvm垃圾回收機制可以考慮配置為 UseG1GC 

  • 即使按照官方說明配置成32G以下,比如31G,在短時間資料量暴增的情況下,容易帶來linux oom問題,如果存在這種情況,建議再配置小一點。

2.檔案控制程式碼問題

       linux中,所有的一切都與檔案有關,實時開啟的檔案控制程式碼數是有限制的,Elasticsearch可以看著是基於檔案的資料庫,隨著資料量的增加,開啟的控制程式碼越來越多,就會導致系統停止對外響應,比如ssh登入不上去等問題。

       這種情況,首先建議調整linux核心引數,修改系統開啟的最大檔案控制程式碼數量。

       其次還是要控制索引的數量,不要無限制的增長下去,想辦法控制同時開啟的檔案控制程式碼數量。

 3.硬碟問題

       硬碟當然是讀寫速度越快越好,資料量比較大的環境可以考慮冷熱資料分離。

       需要注意的是當Elasticsearch資料所在的硬碟空間使用超過80%以上時,就可能出現資料不再寫入該節點的情況,所以需要定時監測硬碟使用量。

       另外,不太建議使用通過網路掛載的硬碟空間。

       總的來說硬碟有關的問題相對少點,就不多說了。

 4.其他問題

       以下的問題,可能是在特定的環境下,特定的版本上出現的。

       執行環境,vmware+centos7.4 , kernel 3.x,3個ES節點,各64G記憶體。

       問題1:3個節點中,有2個資料節點頻繁當機,kernel異常日誌提示watchdog: BUG: soft lockup – CPU#5 stuck for 23s! [java:5783]。

       各種搜尋,建議升級核心版本,大於4.13.0-1017。

       辛辛苦苦給2個節點升級核心,具體方法,自行百度,升級核心的坑就不多說了。

       問題2:升級核心後,問題1基本解決,但是在短時間資料流暴增的情況下,出現OOM問題。

       分析原因,應該還是jvm記憶體設定為31G,es索引底層索引記憶體請求加上jvm記憶體請求可能超出系統總實體記憶體(畢竟還有其他程式也要佔用記憶體),導致OOM問題。解決辦法,jvm記憶體適當調小一點。

       當然也可以調整核心引數,取消OOM特性(不建議在生產環境使用)。

       問題3:最鬱悶的情況,解決完上述兩個問題後,系統平均10多分鐘就當機一次,系統日誌無報錯,只在vcenter控制檯上,提示kernel BUG at       drivers/net/vmxnet3/vmxnet3_drv.c:1441!。繼續搜尋,發現這是vmware的一個bug,在特定情況下出現:

       Linux VM is running kernel >= 4.8

       HW version of VM is >=13

       ESXi version is 6.5

       解決辦法:

              修改虛擬機器vmx配置檔案,新增vmxnet3.rev.30 = FALSE

              或者 設定ethtool -G ethX rx-mini 0,ethX為網路卡名稱

 

相關文章