文章目錄

• 概述
• 系統的重要配置
• 開發模式 vs 生產模式 （Bootstrap Checks）
• 配置系統設置
• • files descriptors
  • • 臨時設置
    • 永久設置
  • 設置jvm option
  • 禁止swapping
  • • （1）禁用所有的swapping file
    • （2）配置swappiness
    • （3）啟用bootstrap.memory_lock
  • 虛擬內存
  • 設置線程的數量
  • DNS cache settings
  • JNA temporary directory not mounted with noexec

---

概述

繼續跟中華石杉老師學習ES，第68篇

課程地址： https://www.roncoo.com/view/55

---

系統的重要配置

理想情況下，es應該單獨在一個服務器上運行，能夠使用服務器上的所有資源。為了達到上述目標，我們需要配置操作系統，來允許用戶運行es并且獲取比默認情況下更多的資源。

在生產環境中下面的一些設置必須配置一下：

（1）禁止swapping
（2）確保擁有足夠的虛擬內存
（3）確保擁有足夠的線程數量

---

開發模式 vs 生產模式 （Bootstrap Checks）

https://www.elastic.co/guide/en/elasticsearch/reference/current/system-config.html#dev-vs-prod

默認情況下，es會假設你是在開發模式下運行的。如果上面的任何配置沒有正確的設置，那么會輸出一些warning到日志文件中，但是我們還是可以啟動es進程的。

從5.0開始，ES加入了Bootstrap Checks ，Elasticsearch 會在啟動時進行 Bootstrap Checks。Bootstrap Checks 會檢查很多 Elasticsearch 和系統的配置。在開發模式下，所有沒通過的檢查都會報 warnings 并寫進日志文件，即使檢查沒通過，依然可以啟動節點運行 Elasticsearch；而在生產模式下，任何沒通過的 Bootstrap Checks 都會報異常并阻止 Elasticsearch 啟動 。

比如我們配置了網絡設置，比如network.host，es會認為我們是運行在生產環境中的，然后就會將上述warning升級為exception。這些exception會阻止我們的es節點啟動。

這是一個重要的安全保障措施來確保我們不會因為錯誤的配置了es server，而導致數據丟失。

比如你可能碰到

ERROR: [1] bootstrap checks failed [1]: initial heap size [1073741824] not equal to maximum heap size [2147483648]; this can cause resize pauses and prevents mlockall from locking the entire heap

---

配置系統設置

setting-system-settings： https://www.elastic.co/guide/en/elasticsearch/reference/current/setting-system-settings.html

files descriptors

在/etc/security/limits.conf中，可以配置系統設置 ，也可以用ulimit臨時配置系統設置

臨時設置

在linux操作系統中，ulimit可以用來臨時的改變資源限制。通常需要用root權限來設置ulimit。

舉例，如果要設置file descriptor為65536，可以用如下的命令來設置：

ulimit -n 65536

---

永久設置

但是在linux操作系統中，實際上永久性的資源限制可以通過編輯**/etc/security/limits.conf**文件來設置。比如要設置file descriptor，可以再limits.conf中加入下面的行：

elasticsearch - nofile 65536

在下一次elasticsearch用戶開啟一個新的會話時就會生效

https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html

---

設置jvm option

一般建議通過jvm.options配置文件來設置es的jvm option。默認的地址是config/jvm.options

每行是一個jvm argument

此外，如也可以通過ES_JAVA_OPTS環境變量來設置jvm option，比如下面的命令：

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

---

禁止swapping

官網指導： https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html

大多數操作系統都會使用盡量多的內存來進行file system cache，并且盡量將不經常使用的java應用的內存swap到磁盤中去。這會導致jvm heap的部分內存，甚至是用來執行代碼的內存頁被swap到磁盤中去。下次讀取 ，內存中不存在又需要從磁盤重新讀取，必然影響性能。

swapping對于性能來說是非常差勁的，為了es節點的穩定性考慮，應該盡量避免這種swapping。因為swapping會導致gc過程從毫秒級變成分鐘級，在gc的時候需要將內存從磁盤中swapping到內存里，特別耗時，這會導致es節點響應請求變得很慢，甚至導致es node跟cluster失聯。

在一個彈性的分布式系統中，讓操作系統kill掉某一個節點，是很高效的。

有三種方法可以disable swapping。推薦的option是徹底禁用swap，如果做不到的化，也得盡量最小化swappiness的影響，比如通過lock memory的方法。

（1）禁用所有的swapping file

通常來說，es進程會在一個節點上單獨運行，那么es進程的內存使用是由jvm option控制的。

可以使用下面的命令臨時性禁止swap：swapoff -a

要永久性的禁止swap，需要修改/etc/fstab文件，然后將所有包含swap的行都注釋掉

---

（2）配置swappiness

另外一個方法就是通過sysctl，將vm.swappiness設置為1，這可以盡量減少linux內核swap的傾向，在正常情況下，就不會進行swap，但是在緊急情況下，還是會進行swap操作。sysctl -w vm.swappiness=1

---

（3）啟用bootstrap.memory_lock

最后一個選項，就是用mlockall，將es jvm進程的address space鎖定在內存中，阻止es內存被swap out到磁盤上去。

在config/elasticsearch.yml中，可以配置：

bootstrap.memory_lock: true

GET _nodes?filter_path=**.mlockall，通過這行命令可以檢查mlockall是否開啟了

如果發現mlockall是false，那么意味著mlockall請求失敗了。會看到一行日志，unable to lock jvm memory。

最大可能的原因，就是在linux系統中，啟動es進程的用戶沒有權限去lock memory，需要通過以下方式進行授權：

ulimit -l unlimited

/etc/security/limits.conf，memlock設置為unlimited

另外一個原因可能是臨時目錄使用noexec option來mount了。可以通過指定一個新的臨時目錄來解決

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

當然也可以通過在jvm.options文件中來設置java.io.tmpdir

---

虛擬內存

官方文檔： https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html

es使用mmapfs 目錄來存儲index數據，操作系統的默認mmap count限制是很低的，可能會導致內存耗盡的異常。

需要提升mmap count的限制：sysctl -w vm.max_map_count=262144

如果要永久性設置這個值，要修改**/etc/sysctl.conf**，將vm.max_map_count的值修改一下，重啟過后，用sysctl vm.max_map_count來驗證一下數值是否修改成功

---

設置線程的數量

官方指導： https://www.elastic.co/guide/en/elasticsearch/reference/current/max-number-of-threads.html

es用了很多線程池來應對不同類型的操作，在需要的時候創建新的線程是很重要的。要確保es用戶能創建的最大線程數量至少在4096以上。

可以通過ulimit -u 4096來臨時設置，也可以在/etc/security/limits.conf中設置nproc為4096來永久性設置。

---

DNS cache settings

https://www.elastic.co/guide/en/elasticsearch/reference/current/networkaddress-cache-ttl.html

Elasticsearch在適當的位置運行安全管理器。

有了安全管理器，JVM默認將無限期地緩存正主機名解析，并且默認將十秒內緩存負主機名解析。

Elasticsearch使用默認值覆蓋此行為，以將正向查找緩存六十秒，并將負向查找緩存十秒。這些值應適用于大多數環境，包括DNS分辨率隨時間變化的環境。

如果沒有，您可以 在JVM選項中編輯值es.networkaddress.cache.ttl和es.networkaddress.cache.negative.ttl。需要注意的是價值 和 在 Java安全策略由Elasticsearch忽略，除非你刪除的設置 和。

es.networkaddress.cache.negative.ttlnetworkaddress.cache.ttl=<timeout>networkaddress.cache.negative.ttl=<timeout>es.networkaddress.cache.ttles.networkaddress.cache.negative.ttl

---

JNA temporary directory not mounted with noexec

這僅與Linux有關。

Elasticsearch使用Java本機訪問（JNA）庫來執行一些平臺相關的本機代碼。

在Linux上，在運行時從JNA存檔中提取支持該庫的本機代碼。默認情況下，此代碼被提取到Elasticsearch臨時目錄，該目錄默認為的子目錄 /tmp。或者，可以使用JVM標志來控制此位置 -Djna.tmpdir=<path>。

由于本機庫以可執行文件的形式映射到JVM虛擬地址空間中，因此必須不將提取此代碼的位置的基礎掛載點掛載，noexec因為這會阻止JVM進程將此代碼映射為可執行文件。

在某些加固的Linux安裝中，這是默認的安裝選項/tmp。表示已安裝基礎掛載的一種跡象noexec是，在啟動時，JNA將無法加載，并且java.lang.UnsatisfiedLinkerError帶有一條類似的消息failed to map segment from shared object。

請注意，在JVM版本之間，異常消息可能有所不同。此外，依賴于通過JNA執行本機代碼的Elasticsearch組件將失敗，并顯示指示其為的消息because JNA is not available。如果看到這樣的錯誤消息，則必須重新掛載JNA所用的臨時目錄，以使其無法掛載noexec。

總結

以上是生活随笔為你收集整理的白话Elasticsearch68-ES生产集群部署重要的操作系统设置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。