環境

CentOS-7-x86_64-DVD-2009.iso

https://mirrors.aliyun.com/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-2009.iso

elasticsearch-7.10.0-linux-x86_64.tar.gz

https://www.elastic.co/cn/downloads/past-releases/elasticsearch-7-10-0

https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.10.0-linux-x86_64.tar.gz

安裝

# mkdir -p /usr/local/elasticsearch
# chown esuser:esuser /usr/local/elasticsearch
# useradd esuser
# passwd esuser
# su - esuser
$ mv elasticsearch-7.10.0-linux-x86_64.tar.gz /usr/local/elasticsearch/
$ cd /usr/local/elasticsearch/
$ tar -xvzf elasticsearch-7.10.0-linux-x86_64.tar.gz 
$ cd elasticsearch-7.10.0
$ ls
bin  config  jdk  lib  LICENSE.txt  logs  modules  NOTICE.txt  plugins  README.asciidoc

注意：默認情況下，不允許使用root用戶運行ES，會報錯：

Caused by: java.lang.RuntimeException: can not run elasticsearch as root

前臺運行

$ ./bin/elasticsearch

驗證是否啟動成功

$ curl localhost:9200/
{
  "name" : "localhost.localdomain",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "8CLFbx4LSwW_maztFPGiTg",
  "version" : {
    "number" : "7.10.0",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "51e9d6f22758d0374a0f3f5c6e8f3a7997850f96",
    "build_date" : "2020-11-09T2133.964949Z",
    "build_snapshot" : false,
    "lucene_version" : "8.7.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

說明：訪問地址要和config/elasticsearch.yml中network.host配置保持一致

后臺運行

要將ES作為守護進程運行，請在命令行上指定-d，并使用-p選項將進程ID記錄在文件中：

如果對ES密鑰庫進行了密碼保護，系統將提示你輸入密鑰庫的密碼。有關更多詳細信息，請參閱安全設置。日志消息可以在$ES_HOME/logs/目錄中找到。

$ ./bin/elasticsearch -d -p pid

關閉以守護進程方式啟動的ES,，殺死pid文件中記錄的進程ID：

$ pkill -F pid

參考鏈接

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/install-elasticsearch.html

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/targz.html#install-linux

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/targz.html#targz-running

配置

重要的Elasticsearch配置

Path配置

ES將索引的數據寫入索引，并將數據流寫入data目錄。ES將自己的應用程序日志寫入logs目錄，其中包含有關集群健康和操作的信息。

對于macOS.tar.gz、Linux.tar.gz和Windows.zip安裝，默認情況下data和logs是$ES_HOME的子目錄。但是，$ES_HOME中的文件在升級過程中有被刪除的風險。

在生產環境中，強烈建議將$ES_HOME/config/elasticsearch.yml中的path.data和path.logs設置為$ES_HOME之外的位置

類Unix系統中配置示例：

path:
  data: /var/data/elasticsearch
  logs: /var/log/elasticsearch

如果有必要，可以在path.data中指定多個路徑。ES在所有提供的路徑上存儲節點的數據，但將每個分片的數據保持在同一路徑上。

注意：

ES不會在節點的數據路徑上均衡分片。單個路徑中的高磁盤使用率會觸發整個節點磁盤使用率高水位。如果觸發，ES將不會向節點添加分片，即使節點的其他路徑有可用的磁盤空間。如果需要額外的磁盤空間，建議添加一個新節點，而不是額外的數據路徑。

Linux和macOS安裝path.data支持多個類Unix風格路徑：

path:
  data:
    - /mnt/elasticsearch_1
    - /mnt/elasticsearch_2
    - /mnt/elasticsearch_3

集群名稱配置

一個節點只有在與集群中的所有其他節點共享其cluster.name時才能加入集群。默認名稱是elasticsearch，但應該將其更改為描述集群用途的適當名稱。

cluster.name: logging-prod

節點名稱配置

ES使用node.name作為ES特定實例的易讀標識符。此名稱包含在許多API的響應中。ES啟動時，節點名默認為機器的主機名，但可以在elasticsearch.yml中顯式配置：

node.name: prod-data-2

網絡主機配置

默認情況下，ES只綁定到環回地址，如127.0.0.1和[::1]。此綁定足以在服務器上運行單個開發環境節點

注意：

可以從單個節點上的相同$ES_HOME位置啟動多個節點。此設置可用于測試ES形成集群的能力，但不建議用于生產環境。

要與其他服務器上的節點形成集群，節點需要綁定到非環回地址。雖然有許多網絡設置，但通常只需配置network.host即可：

network.host: 192.168.1.10

network.host設置還可以理解一些特殊值，如_local_,_site_,_global_和修飾符，如:ip4和:ip6。請參閱network.host特殊值。

Discovery和集群信息配置

在投入生產之前，配置兩個重要的集群發現和形成設置，以便集群中的節點可以相互發現并選擇master節點。

discovery.seed_hosts

開箱即用，無需任何網絡配置，ES將綁定到可用的環回地址，并掃描本地端口9300到9305，以與同一服務器上運行的其他節點連接。這種行為提供了一種自動集群體驗，而無需進行任何配置。
當希望與其他主機上的節點形成集群時，使用靜態“discovery.seed_hosts設置。此設置提供集群中其他節點的列表，這些節點符合master節點資格，可能處于活動狀態并可聯系，以啟動發現過程. 此設置接受集群中所有符合master節點條件的節點的YAML序列或地址數組。每個地址可以是IP地址，也可以是通過DNS解析為一個或多個IP地址的主機名。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 
   - seeds.mydomain.com 
   - [000c0a8:10c]:9301 

端口號可選，默認為9300, 可修改。

如果主機名解析為多個IP地址，則節點將嘗試在所有已解析的地址上發現其他節點。

IPv6地址必須括在方括號內

如果符合master節點條件的節點沒有固定的名稱或地址，使用可選主機提供商動態查找其地址。

cluster.initial_master_nodes

第一次啟動ES集群時，cluster bootstrapping步驟確定了在第一次選舉中投票的符合master節點資格的節點集。在開發模式下，在沒有配置發現設置的情況下，此步驟由節點本身自動執行。

因為自動引導本質上是不安全的，在生產模式下啟動新集群時，必須明確列出符合master節點資格的節點，這些節點的投票應在第一次選舉中被計算。可以使用cluster.initial_master_nodes設置來設置此列表。

在集群首次成功建立后，從每個節點的配置中刪除cluster.initial_master_nodes設置。重新啟動群集或向現有群集添加新節點時，請勿使用此設置。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11
   - seeds.mydomain.com
   - [000c0a8:10c]:9301
cluster.initial_master_nodes: 
   - master-node-a
   - master-node-b
   - master-node-c

通過node.name標識初始master節點(https://www.elastic.co/guide/en/elasticsearch/reference/7.10/important-settings.html#node-name），默認為其主機名。確保cluster.initial_master_nodes中的值與node.name完全匹配。如果使用完全限定域名(FQDN)作為節點名稱，例如master-node-a.example.com，則必須使用此列表中的FQDN。相反，如果node.name是一個沒有任何尾隨限定符的裸主機名，則還必須省略cluster.initial_master_nodes中的尾隨限定符。

查閱bootstrapping a cluster

堆大小配置

默認情況下，ES告訴JVM使用一個最小和最大值都為1GB的堆。當部署到生產環境時，配置堆大小以確保ES有足夠的可用堆空間非常重要。

ES將通過Xms（最小堆大小）和Xmx（最大堆大小）設置分配jvm.options中指定的整個堆。Xms和Xmx設置必須彼此相等。

這些設置的值取決于服務器上可用的RAM量：

將Xmx和Xms設置為不超過物理RAM的50%。ES需要內存用于JVM堆以外的目的，為此留出空間非常重要。例如，ES使用堆外緩沖區進行高效的網絡通信，依賴于操作系統的文件系統緩存來高效訪問文件，JVM本身也需要一些內存。ES進程使用的內存超過使用Xmx設置配置的限制是正常的。

將Xmx和Xms設置為不超過JVM用于壓縮對象指針的閾值。確切的閾值各不相同，但接近32GB。可以通過在日志中查找類似以下行來驗證是否低于閾值:

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

將Xmx和Xms設置為不超過從零開始的壓縮oops的閾值。確切的閾值各不相同，但26 GB在大多數系統上是安全的，在某些系統上可能高達30 GB。可以通過使用JVM選項-XX+PrintCompressedOopsMode啟動ES，并查找類似以下行來驗證是否低于此閾值:

heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops

此行顯示啟用了從零開始的壓縮oops。如果未啟用從零開始的壓縮oops，你將看到類似以下行:

heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000

ES可用的堆越多，它可以用于內部緩存的內存就越多，但留給操作系統用于文件系統緩存的內存越少。此外，較大的堆可能會導致垃圾收集暫停時間更長。

下面是一個如何通過config/jvm.options.d/文件設置堆大小的示例：

-Xms2g 
-Xmx2g

將最小堆內存和最大堆內存都設置為 2g。

使用jvm.options.d是配置生產部署堆大小的首選方法。

備注：默認情況下，jvm.options.d為空目錄，可以在該目錄下手動新建配置，如jvm.options，文件格式可參考config/jvm.options

還可以通過ES_JAVA_OPTS環境變量設置堆大小。這通常不建議用于生產部署，但對于測試很有用，因為它覆蓋了設置JVM選項的所有其他方式。

ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch 
ES_JAVA_OPTS="-Xms4000m -Xmx4000m" ./bin/elasticsearch

1 設置最小堆內存和最大堆內存都為 2g。

2 設置最小堆內存和最大堆內存都為 4000 MB。

JVM 堆 dump路徑設置

默認情況下，ES 配置JVM 將內存不足的堆dump到默認數據目錄。RPM以及Debian包，數據目錄為/var/lib/eelasticsearch。在Linux 和 MacOS 和Windows發行版中，data目錄位于ES安裝的根目錄下。如果此路徑不適合接收堆dump，則修改jvm.options中-XX:HeapDumpPath=…條目:

如果指定了一個目錄，JVM將根據運行實例的PID為堆dump生成一個文件名。

如果指定固定文件名而不是目錄，則當JVM需要對內存不足的異常執行堆dump時，該文件必須不存在。否則，堆dump將失敗。

GC日志配置

默認情況下，ES啟用垃圾收集(GC)日志。這些是在jvm.options配置的并且輸出到與ES日志相同的默認位置。默認配置每64 MB輪換一次日志，最多可消耗2 GB的磁盤空間。

可以使用JEP 158: 統一JVM日志中描述的命令行選項重新配置JVM日志記錄。除非直接更改默認的jvm.options文件，否則除了你自己的設置外，還會應用ES默認配置。要禁用默認配置，首先通過提供-Xlog:disable選項禁用日志，然后提供自己的命令行選項。這將禁用所有JVM日志，因此務必查看可用選項并啟用所需的一切。

要查看原始JEP中未包含的更多選項，請參閱使用JVM統一日志框架啟用日志。

Examples

通過創建帶有一些示例選項的$ES_HOME/config/jvm.options.d/GC.options，將默認GC日志輸出位置更改為/opt/my-app/gc.log：

# 關閉之前所有的日志記錄配置
-Xlog:disable

# JEP 158的默認設置，除了使用“utctime”而不是“uptime”來匹配下一行 
-Xlog:all=warningutctime,level,tags

# 使用各種選項將GC日志記錄到自定義位置
-Xlog:gc*,gc+age=trace,safepoint:file=/opt/my-app/gc.log:utctime,pid,tags:filecount=32,filesize=64m

配置ESDocker容器將GC調試日志發送到標準錯誤（stderr）。這使容器編排器能夠處理輸出。如需使用ES_JAVA_OPTS環境變量，請指定：

MY_OPTS="-Xlog:disable -Xlog:all=warningutctime,level,tags -Xlog:gc=debugutctime"
docker run -e ES_JAVA_OPTS="$MY_OPTS" # etc

臨時目錄設置

默認情況下，ES使用啟動腳本在系統臨時目錄下創建的私有臨時目錄。

在某些Linux發行版上，系統實用程序會將最近沒有訪問過的文件和目錄將從/tmp中刪除。這將導致ES運行期間私有臨時目錄被刪除，如果需要使用臨時目錄的功能長時間未使用的話。后續如果某些功能使用需要此臨時目錄，將會產生問題。

如果使用.deb或.rpm包安裝ES，并在systemd下運行它，ES使用的私有臨時目錄將被排除在定期清理之外。

如果打算在Linux或MacOS上長時間運行.tar.gz發行版，考慮為ES創建一個專用的臨時目錄，將該目錄設置在不會從中清除舊文件和目錄的路徑下。此目錄應設置權限，以便只有運行ES的用戶可以訪問它。然后，在啟動ES之前，將$ES_TMPDIR環境變量設置為指向此目錄

JVM致命錯誤日志設置

默認情況下，ES配置JVM將致命錯誤日志寫入默認日志目錄。針對RPM以及Debian包，該目錄為/var/log/elasticsearch。針對Linux，MacOS和Windows發行版中，logs目錄位于ES安裝目錄的根目錄下。

這些日志是JVM在遇到致命錯誤（如分段錯誤）時生成的日志。如果此路徑不適合接收日志，則修改jvm.options中-XX:ErrorFile=…條目

集群備份

快照可以防止因為災害導致的永久數據丟失。快照生命周期管理是對集群進行定期備份的最簡單方法。有關更多信息，請參閱集群備份.
注意：

不能通過簡單地復制ES集群所有節點的數據目錄來備份ES。ES在運行時可能會對其數據目錄的內容進行更改；復制其數據目錄不能保證其內容的一致性。備份群集的唯一可靠方法是使用快照和還原功能。

參考鏈接

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/important-settings.html

重要的系統配置

配置系統設置

在哪配置系統設置取決于用于安裝ES的軟件包以及使用的操作系統。

當使用.zip或.tar.gz包時，可以配置系統設置：

使用ulimit臨時配置，或

在/etc/security/limits.conf中永久配置

使用RPM或Debian軟件包時，大多數系統設置都在 系統配置文件 中設置. 然后，使用systemd的系統要求在 systemd配置文件 中指定系統限制

ulimit

在Linux系統上，ulimit可用于臨時更改資源限制。通常需要在運行ES的用戶啟動ES前，切換為root，以配置資源限制。例如，要將打開的文件句柄數（ulimit-n）設置為65536，可以執行以下操作：

sudo su  
ulimit -n 65535 
su esuser

新的資源配置僅應用于當前會話。可通過ulimit -a查詢當前所有限制。

/etc/security/limits.conf

在Linux系統上，可以通過編輯/etc/security/limits.conf文件為特定用戶設置持久限制。例如，要將esuser用戶的最大打開文件數設置為65535，在limits.conf文件中添加以下行：

esuser  -  nofile  65535

此更改僅在elasticsearch用戶下次打開新會話時生效。

Ubuntu下的limits.conf

Ubuntu會忽略由init.d啟動的進程的limits.conf文件。要啟用limits.conf文件，請編輯/etc/pam.d/su并取消注釋以下行:

# session    required   pam_limits.so

系統配置文件

使用RPM或Debian軟件包時，可以在系統配置文件中指定系統設置和環境變量，該文件位于：

包類型	系統配置文件路徑
RPM	/etc/sysconfig/elasticsearch
Debian	/etc/default/elasticsearch

但是，對于使用systemd的系統，需要通過systemd指定系統限制

Systemd配置

在使用systemd的系統上使用RPM或Debian軟件包時，必須通過systemd指定系統限制。

systemd服務文件（/usr/lib/systemd/system/eelasticsearch.service）包含默認應用的限制。

要覆蓋它們，添加一個名為/etc/systemd/system/exelasticsearch.service.d/overrid.conf的文件（或者，運行sudo systemctl edit elasticsearch，會在默認編輯器中自動打開該文件）。在此文件中設置任何需要的變更，例如：

[Service]
LimitMEMLOCK=infinity

一旦完成更改，運行以下命令以重載服務單元：

sudo systemctl daemon-reload

參考鏈接

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

禁用交換(swapping)

大多數操作系統都試圖將盡可能多的內存用于文件系統緩存，并急切地交換掉未使用的應用程序內存。這可能會導致JVM堆的一部分，甚至其可執行頁面被換出到磁盤。

swapping 對性能和節點穩定性非常不利，應該不惜一切代價避免。它可能會導致垃圾收集持續分鐘而不是毫秒，并可能導致節點響應緩慢，甚至與集群斷開連接。在彈性分布式系統中，更容易導致操作系統殺死節點。

有三種方法可以禁用交換。首選項是完全禁用交換。如果這不是一種選擇，那么是選擇最小化swappiness還是選擇內存鎖定取決于你的環境

禁用所有swap文件

通常，ES是在機器上運行的唯一服務，其內存使用由JVM選項控制。不需要啟用交換。

在Linux系統上，可以通過運行以下命令暫時禁用交換：:

sudo swapoff -a

這不需要重新啟動Elasticsearch。

要永久禁用，則需要編輯/etc/fstab文件，并注釋掉任何包含單詞swap的行。

在Windows上，可以通過系統屬性→高級→性能→高級→虛擬內存完全禁用分頁文件來實現等效功能。

配置swappiness

Linux系統上可用的另一個選擇是確保sysctl值vm.swappiness設置為1。這減少了內核交換的傾向，在正常情況下不應導致交換，同時仍然允許整個系統在緊急情況下交換。

開啟bootstrap.memory_lock

另一種選擇是在Linux/Unix系統上使用mlockall，在Windows上使用VirtualLock，以嘗試將進程地址空間鎖定到RAM中，防止任何ES堆內存被換出。

一些平臺在使用內存鎖時仍然會交換堆內存。為了防止堆外內存交換，取而代之，禁用所有交換文件。

要啟用內存鎖，需在elasticsearch.yml中將bootstrap.memory_lock設置為true：

bootstrap.memory_lock: true

如果mlockall試圖分配的內存超過可用內存，則可能會導致JVM或shell會話退出！

啟動Elasticsearch后，可以通過檢查此請求輸出中mlockall值來查看此設置是否已成功應用：

GET _nodes?filter_path=**.mlockall

如果看到mlockall為false，則意味著mlockall請求失敗。還將在日志中看到一行包含更多信息，帶有單詞Unable to lock JVM Memory的日志。

在Linux/Unix系統上，最可能的原因是運行Elasticsearch的用戶沒有鎖定內存的權限。可以按如下方式授權：

使用.zip和.tar.gz安裝包

啟動ES前以root用戶執行ulimit -l unlimited。可選的，設置/etc/security/limits.confmemlock為unlimited

# allow user 'elasticsearch' mlockall
elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited

RPM 和 Debian

系統配置文件中設置MAX_LOCKED_MEMORY為unlimited

使用systemd的系統

systemd配置中設置LimitMEMLOCK為infinity

mlockall失敗的另一個可能原因是JNA臨時目錄(通常是/tmp的子目錄)是用noexec選項掛載的。這可以通過使用ES_JAVA_OPTS環境變量為JNA指定一個新的臨時目錄來解決：

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djna.tmpdir="
./bin/elasticsearch

或者在jvm.options配置文件中設置該JVM標識。

參考鏈接

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/setup-configuration-memory.html

文件描述符

這僅適用于Linux和MacOS，如果在Windows上運行ES，可以安全地忽略它。在Windows上，JVM使用僅受可用資源的限制的API。

ES使用了大量的文件描述符或文件句柄。文件描述符用盡可能是災難性的，很可能會導致數據丟失。確保將運行ES的用戶的打開文件描述符數量限制增加到65536或更高。

對于.zip和.tar.gz包，在啟動ES之前以root用戶設置ulimit -n 65535，或者在/etc/security/limits.conf中將nofile設置為65535。

在MacOS上，還必須將JVM選項-XX:-MaxFDLimit傳遞給ES，以便使用更高的文件描述符限制。

RPM和Debian軟件包已經將文件描述符的最大數量默認為65535，不需要進一步配置。

可以使用Nodes stats檢查為每個節點配置的max_file_descriptors:

GET _nodes/stats/process?filter_path=**.max_file_descriptors

參考鏈接

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

虛擬內存

默認情況下，ES使用mmapfs目錄用于存儲其索引。默認操作系統對mmap計數的限制可能太低，這可能會導致內存不足異常。

在Linux上，可以通過以root身份運行以下命令來增加限制。

sysctl -w vm.max_map_count=262144

要永久設置該值，需更新/etc/sysctl.conf中的vm.max_map_count設置。要在重新啟動后進行驗證，請運行sysctl vm.map_map_count。

RPM和Debian軟件包將自動配置此設置。無需進一步配置。CentOS7.9中驗證，該配置項默認為65535，無法正常啟動

參考鏈接

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/vm-max-map-count.html

線程數量

ES為不同類型的操作使用了許多線程池。重要的是，它能夠在需要時創建新線程。確保Elasticsearch用戶至少可創建4096個線程。

這可以通過在啟動Elasticsearch之前以root用戶運行ulimit -u 4096來完成 ，或者在/etc/security/limits.conf中將nproc設置為4096。

發行包在systemd下作為服務運行時，將自動配置ES進程的線程數。不需要額外的配置。

參考鏈接

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/max-number-of-threads.html

DNS緩存設置

ES運行時有一個安全管理器。有了安全管理器，JVM默認無限期緩存正向主機名解析，默認緩存反向主機名解析10秒。ES使用默認值覆蓋此行為，以緩存正向解析60秒，反向解析10秒。這應適用于大多數環境，包括DNS解析隨時間變化的環境。如果沒有覆蓋此配置，可以編輯JVM選項中的es.networkaddress.cache.ttl和es.networkaddress.cache.negative.ttl。注意，ES會忽略 Java安全策略中的networkaddress.cache.ttl=和networkaddress.cache.negative.ttl=。除非移除es.networkaddress.cache.ttl和es.networkaddress.cache.notanegative.ttl設置。

參考鏈接

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

JNA臨時目錄未使用noexec掛著

這僅適用于Linux。

ES使用Java Native Access(JNA)庫來執行一些依賴于平臺的本地代碼。在Linux上，支持此庫的本地代碼在運行時從JNA存檔中提取。默認情況下，此代碼被提取到ES臨時目錄，該目錄默認為/tmp的子目錄。可選的，可以使用JVM標志-Djna.tmpdir=控制此位置。由于本地庫作為可執行文件映射到JVM虛擬地址空間，因此提取此代碼的位置的底層掛載點不能使用noexec掛載，因為這會阻止JVM進程將此代碼映射為可執行文件。在一些強化的Linux安裝中，這是/tmp的默認掛載選項。底層掛載是用noexec掛載的一個跡象是，在啟動時，JNA將無法加載，提示java.lang.UnsatisfiedLinkerError異常，并顯示一條類似failed to map segment from shared object的提示信息。注意，消息可能因JVM版本差異而不同。此外，依賴于通過JNA執行本地代碼的ES組件將失敗，并顯示because JNA is not available的提示。如果看到此類錯誤信息，則必須重新掛載用于JNA的臨時目錄，并且不使用noexec掛載。

參考鏈接

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/executable-jna-tmpdir.html

TCP重傳超時

集群中的每對節點都通過許多TCP連接進行通信，這些TCP連接保持打開狀態直到其中一個節點關閉或節點之間的通信因底層基礎框架故障而中斷。

TCP通過向通信應用程序隱藏臨時網絡中斷，在偶爾不可靠的網絡上提供可靠的通信。在通知發送者任何問題之前，操作系統將多次重新傳輸任何丟失的消息。大多數Linux發行版默認重新傳輸任何丟失的數據包15次。重傳呈指數級推遲，因此這15次重傳需要900多秒才能完成。這意味著使用此方法檢測網絡分區或故障節點需要消耗Linux幾分鐘的時間。Windows默認只重傳5次，超時時間約為6秒。

Linux默認允許在可能經歷很長一段時間數據包丟失的網絡上進行通信，但對于單個數據中心內的生產網絡來說，這個默認值是過高的，正如大多數Elasticsearch集群一樣。高可用集群必須能夠快速檢測節點故障，以便通過重新分配丟失的分片、重新路由搜索以及可能選擇新的主節點來迅速做出反應。因此，Linux用戶應該減少TCP重傳的最大次數。

可以通過以root身份運行以下命令，將TCP重傳的最大次數減少到5。五次重傳對應的超時時間約為六秒。

sysctl-w net.ipv4.tcp_reres2=5

要永久設置此值，更新/etc/sysctl.conf中的net.ipv4.tcp_reres2設置。要在重新啟動后運行sysctl net.ipv4.tcp_reres2查看是否生效。

此設置適用于所有TCP連接，也會影響與群體外系統的通信可靠性。如果的集群通過不可靠的網絡與外部系統通信，則可能需要為net.ipv4.tcp_reres2選擇更高的值。因此，Elasticsearch不會自動調整此設置。

相關配置

ES還實現了自己的內部健康檢查，超時時間比Linux上的默認重傳超時時間短得多。由于這些是應用程序級健康檢查，因此它們的超時必須考慮到應用程序級的影響，如垃圾收集暫停。不應該減少與這些應用程序級健康檢查相關的任何超時。

鏈接：https://www.cnblogs.com/shouke/p/18551220