ElasticSearch優化系列二：機器設置（內存）

歡迎關注我們的微信公眾號「人工智慧LeadAI」（ID：atleadai）

預留一半內存給Lucence使用

一個常見的問題是配置堆太大。你有一個64 GB的機器，覺得JVM內存越大越好，想給Elasticsearch所有64 GB的內存。

當然，內存對於Elasticsearch來說絕對是重要的，用於更多的內存數據提供更快的操作。而且還有一個內存消耗大戶-Lucene

Lucene的設計目的是把底層OS里的數據緩存到內存中。Lucene的段是分別存儲到單個文件中的，這些文件都是不會變化的，所以很利於緩存，同時操作系統也會把這些段文件緩存起來，以便更快的訪問。

Lucene的性能取決於和OS的交互，如果你把所有的內存都分配給Elasticsearch，不留一點給Lucene，那你的全文檢索性能會很差的。

最後標準的建議是把50%的內存給elasticsearch，剩下的50%也不會沒有用處的，Lucene會很快吞噬剩下的這部分內存。

32GB限制

給ES的內存配置不是越大越好，建議不能超過32GB，不同jdk版本最大邊界值是不同的，對於32位小於32G JVM才採用內存對象指針壓縮技術，不然對象指針需要佔用很大的內存。

使用如下命令測試最大邊界值：

java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops nbool UseCompressedOops = false {lp64_product} njava -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops n bool UseCompressedOops = true {lp64_product} n$ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops nbool UseCompressedOops := truen $ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOopsnbool UseCompressedOops = falsen

在ES啟動日誌中最好能夠看到壓縮對象指針為真。

heap size [15.8gb], compressed ordinary object pointers [true]

對於32位系統，你的內存最大可使用4G。對於64系統可以使用更大的內存。但是64位的指針意味著更大的浪費，因為你的指針本身大了。浪費內存不算，更糟糕的是，更大的指針在主內存和緩存器（例如LLC, L1等）之間移動數據的時候，會佔用更多的帶寬。

java 使用一個叫內存指針壓縮的技術來解決這個問題。它的指針不再表示對象在內存中的精確位置，而是表示偏移量。這意味著32位的指針可以引用40億個對象，而不是40億個位元組。最終，也就是說堆內存長到32G的物理內存，也可以用32bit的指針表示。

一旦你越過那個神奇的30-32G的邊界，指針就會切回普通對象的指針，每個對象的指針都變長了，就會使用更多的CPU內存帶寬，也就是說你實際上失去了更多的內存。事實上當內存到達40-50GB的時候，有效內存才相當於使用內存對象指針壓縮技術時候的32G內存。

這段描述的意思就是說：即便你有足夠的內存，也盡量不要超過32G，因為它浪費了內存，降低了CPU的性能，還要讓GC應對大內存。

機器內存大於64GB

你可以考慮一台機器上創建兩個或者更多ES節點，而不要部署一個使用32+GB內存的節點。仍然要 堅持50%原則，假設 你有個機器有128G內存，你可以創建兩個node，使用32G內存。也就是說64G內存給ES的堆內存，剩下的64G給Lucene。

如果你選擇第二種，你需要配置cluster.routing.allocation.same_shard.host:true。這會防止同一個shard的主副本存在同一個物理機上（因為如果存在一個機器上，副本的高可用性就沒有了）

swapping是性能的墳墓

這是顯而易見的，但是還是有必要說的更清楚一點，內存交換到磁碟對伺服器性能來說是致命的。想想看一個內存的操作必須是快速的。

如果內存交換到磁碟上，一個100微秒的操作可能變成10毫秒，再想想那麼多10微秒的操作時延累加起來。不難看出swapping對於性能是多麼可怕。

最好的辦法就是在你的操作系統中完全禁用swapping。這樣可以暫時禁用：

sudo swapoff -a

為了永久禁用它，你可能需要修改/etc/fstab文件，這要參考你的操作系統相關文檔。

如果完全禁用swap，對你來說是不可行的。你可以降低swappiness 的值，這個值決定操作系統交換內存的頻率。這可以預防正常情況下發生交換。但仍允許os在緊急情況下發生交換。對於大部分Linux操作系統，可以在sysctl 中這樣配置：

vm.swappiness = 1

備註：swappiness設置為1比設置為0要好，因為在一些內核版本，swappness=0會引發OOM（內存溢出）

最後，如果上面的方法都不能做到，你需要打開配置文件中的mlockall開關，它的作用就是運行JVM鎖住內存，禁止OS交換出去。在elasticsearch.yml配置如下：

bootstrap.mlockall: true

未完待續