參考：
https://www.elastic.co/guide/cn/elasticsearch/guide/current/important-configuration-changes.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html
https://blog.csdn.net/thomas0yang/article/details/55518105
https://www.cnblogs.com/ginb/p/7027910.html
硬件方面
內存
首先最重要的資源是內存，排序和聚合都可能導致內存匱乏，因此足夠的堆空間來容納這些是重要的。即使堆比較小，也要給操作系統高速緩存提供額外的內存，因為Lucene使用的許多數據結構是基於磁盤的格式，Elasticsearch利用操作系統緩存有很大的影響。
64GB RAM的機器是最理想的，但32GB和16GB機器也很常見。少於8GB往往適得其反（你最終需要許多，許多小機器），大於64GB可能會有問題，我們將在討論在堆：大小和交換。
CPU
大多數Elasticsearch部署往往對CPU要求很不大。因此，確切的處理器設置比其他資源更重要，應該選擇具有多個內核的現代處理器。通用集群使用2到8核機器。
如果需要在較快的CPU或更多核之間進行選擇，請選擇更多核。 多核提供的額外並發將遠遠超過稍快的時鍾速度。
硬盤
磁盤對於所有集群都很重要，尤其是對於索引很重的集群（例如攝取日志數據的磁盤）。 磁盤是服務器中最慢的子系統，這意味着大量寫入的群集可以輕松地飽和其磁盤，這反過來成為群集的瓶頸。
如果你能買得起SSD，他們遠遠優於任何旋轉磁盤。 支持SSD的節點看到查詢和索引性能方面的提升。
如果使用旋轉磁盤，請嘗試獲取盡可能最快的磁盤（高性能服務器磁盤，15k轉速驅動器）。
使用RAID 0是提高磁盤速度的有效方法，適用於旋轉磁盤和SSD。 沒有必要使用RAID的鏡像或奇偶校驗變體，因為高可用性是通過副本建立到Elasticsearch中。
最后，避免網絡連接存儲（NAS）。 NAS通常較慢，顯示較大的延遲，平均延遲的偏差較大，並且是單點故障。
網絡
快速和可靠的網絡對於分布式系統中的性能顯然是重要的。低延遲有助於確保節點可以輕松地進行通信，而高帶寬有助於分段移動和恢復。現代數據中心網絡（1GbE，10GbE）對於絕大多數集群都是足夠的。
避免跨越多個數據中心的群集，即使數據中心位置非常接近。絕對避免跨越大地理距離的集群。
Elasticsearch集群假定所有節點相等，而不是一半的節點距離另一個數據中心中有150ms。較大的延遲往往會加劇分布式系統中的問題，並使調試和解決更加困難。
與NAS參數類似，每個人都聲稱數據中心之間的管道是穩健的和低延遲。（吹牛）。從我們的經驗，管理跨數據中心集群的麻煩就是浪費成本。
其他
現在可以獲得真正巨大的機器如數百GB的RAM和幾十個CPU內核。 另外也可以在雲平台（如EC2）中啟動數千個小型虛擬機。 哪種方法最好？
一般來說，最好選擇中到大盒子。 避免使用小型機器，因為您不想管理具有一千個節點的集群，而簡單運行Elasticsearch的開銷在這種小型機器上更為明顯。
同時，避免真正巨大的機器。 它們通常導致資源使用不平衡（例如，所有內存正在使用，但沒有CPU），並且如果您必須為每台機器運行多個節點，可能會增加后期的運維復雜性。
操作系統
較大的文件描述符
Lucene使用了非常大量的文件。 並且Elasticsearch使用大量的套接字在節點和HTTP客戶端之間進行通信。 所有這些都需要可用的文件描述符。
可悲的是，許多現代的Linux發行版每個進程允許一個不允許的1024個文件描述符。 這對於一個小的Elasticsearch節點來說太低了，更不用說處理數百個索引的節點了。
您應該將文件描述符計數增加到非常大的值，例如64,000。 這個過程是令人惱火的困難，高度依賴於你的特定操作系統和分布。 請查閱操作系統的文檔以確定如何更改允許的文件描述符計數。
可以使用http://ip:port/_nodes/stats接口process中的open_file_descriptors和max_file_descriptors進行查看。
設置MMap
Elasticsearch還針對各種文件使用NioFS和MMapFS的混合。 確保配置最大映射計數，以便有足夠的虛擬內存可用於mmapped文件。 這可以臨時設置
sysctl -w vm.max_map_count=655300
或者在/etc/sysctl.conf下永久設置vm.max_map_count。查看設置
cat /proc/sys/vm/max_map_count
JVM虛擬機
除非Elasticsearch網站上另有說明，否則應始終運行最新版本的Java虛擬機（JVM）。 Elasticsearch和Lucene都是比較苛刻的軟件。 Lucene的單元和集成測試通常暴露JVM本身的錯誤。這些錯誤的范圍可以從輕微的煩惱到嚴重的segfaults，所以最好是使用最新版本的JVM盡可能。
Java8要好於Java7.Java6不再受支持。可以接受Oracle或OpenJDK。它們的性能和穩定性相當。
如果您的應用程序是用Java編寫的，並且正在使用傳輸客戶端或節點客戶端，請確保運行應用程序的JVM與服務器JVM相同。在Elasticsearch中的幾個位置，使用Java的本機序列化（IP地址，異常等）。不幸的是，Oracle已知改變小版本之間的序列化格式，導致奇怪的錯誤。這種情況很少發生，但最佳做法是保持客戶端和服務器之間的JVM版本相同。
給lucene留下一半的內存空間
一個常見的問題是配置一個太大的堆。你有一個64GB的機器，並且你想給Elasticsearch所有64GB的內存。更多更好？！堆對Elasticsearch絕對重要，它被許多內存數據結構使用以提供快速操作。但是還有另一個主要的內存用戶是堆：Lucene。
Lucene旨在利用底層操作系統來緩存內存中的數據結構。 Lucene段存儲在單獨的文件中，因為段是不可變的，所以這些文件從不改變。這使得它們非常易於緩存，並且底層操作系統將適合的保持segment駐留在內存中以便更快地訪問。這些段包括反向索引（用於全文搜索）和docvalues（用於聚合）。Lucene的性能依賴於與操作系統的這種交互。但是如果你給Elasticsearch的堆提供所有可用的內存，Lucene就不會有任何剩余的內存。這會嚴重影響性能。
標准建議是給Elasticsearch堆提供50％的可用內存，同時保留其他50％的空閑內存。它不會不使用; Lucene會愉快地吞噬剩下的任何東西。
如果你不是聚合在分析的字符串字段（例如你不需要fielddata），你可以考慮降低堆更多。你可以做的堆越小，你可以期望從Elasticsearch（更快的GC）和Lucene（更多的內存緩存）更好的性能。
不要超過32G
事實證明，當堆大小小於32GB時，HotSpot JVM使用一個技巧來壓縮對象指針。可以通過-XX:+PrintFlagsFinal來查看，在es2.2.0后不用設置，啟動后會打印compressed ordinary object pointers [true]
在Java中，所有對象都在堆上分配並由指針引用。Ordinary object pointers（OOP）指向這些對象，並且通常是CPU本地字的大小：32位或64位，取決於處理器。指針引用值的確切字節位置。 對於32位系統，這最大堆大小為4GB。對於64位系統，堆大小可以變得更大，但64位指針的開銷意味着更多的浪費空間，因為指針更大。並且比浪費的空間更糟，當在主存儲器和各種高速緩存（LLC，L1等）之間移動值時，較大的指針占用更多的帶寬。
Java使用一個名為compress oops的技巧來解決這個問題。指針不是指向存儲器中的精確字節位置，而是引用對象偏移。這意味着32位指針可以引用四十億個對象，而不是40億字節。最終，這意味着堆可以增長到大約32 GB的物理大小，同時仍然使用32位指針。
一旦你超越32GB邊界，指針切換回Ordinary object pointers。每個指針的大小增加，使用更多的CPU內存帶寬，並且您有效地丟失了內存。事實上，它需要直到大約40到50GB的分配的堆，你有一個堆的相同有效內存剛剛低於32GB使用壓縮oops。所以即使你有內存，盡量避免跨越32 GB堆邊界。它浪費內存，降低CPU性能，並使GC與大堆爭奪。
swapping是性能的死穴
它應該是顯而易見的，但它明確拼寫出來：將主內存交換到磁盤會破壞服務器性能。 內存中操作是需要快速執行的操作。如果內存交換到磁盤，100微秒操作將花費10毫秒。 現在重復所有其他10us操作的延遲增加。 不難看出為什么交換對於性能來說是可怕的。
1、最好的辦法是在系統上完全禁用交換。 這可以臨時完成：
sudo swapoff -a
要永久禁用則需要編輯/etc/fstab。請查閱操作系統的文檔。
2、如果完全禁用交換不是一個選項，您可以嘗試
sysctl vm.swappiness = 1（查看cat /proc/sys/vm/swappiness）
這個設置控制操作系統如何積極地嘗試交換內存。 以防止在正常情況下交換，但仍然允許操作系統在緊急情況下交換。swappiness值1比0好，因為在一些內核版本上，swappiness為0可以調用OOM-killer。
3、最后，如果兩種方法都不可能，就應該啟用mlockall。 這允許JVM鎖定其內存，並防止它被操作系統交換。 可以在elasticsearch.yml中設置：
bootstrap.mlockall: true
具體配置
服務器的初始化
設置vm.max_map_count=262144
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
創建elasticsearch的啟動用戶
創建普通用戶 es
useradd es
數據目錄和日志目錄需要設置普通用戶es的權限
sudo chmod 777 es* -R
關於證書elastic-certificates.p12
es提供了生成證書的工具elasticsearch-certutil
第一步，生成ca: elastic-stack-ca.p12， 在任意一台服務器上生成
./bin/elasticsearch-certutil ca
第二步，生成cert: elastic-certificates.p12
./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
這個生成elastic-certificates.p12 就是我們需要使用的。
把證書復制到其他的服務器上
生成elastic用戶的密碼
./bin/elasticsearch-setup-passwords interactive
默認的用戶名是elastic
創建一個臨時的超級用戶admin
./bin/elasticsearch-users useradd admin -r superuser
重要配置
path.data
path.logs
cluster.name
node.name
network.host
discovery.seed_hosts (舊版本是discovery.zen.ping.unicast.hosts）
discovery.zen.minimum_master_nodes [3個節點，就寫2，多於3個，就(總數/2 + 1)]
bootstrap.memory_lock （這個是管理swap內存交換的，默認是不使用swap，建議使用默認）
cluster.name: es-cluster
node.name: es-node1
path.data: /elasticsearch/elasticsearch/data/
path.logs: /elasticsearch/elasticsearch/logs
path.repo: /elasticsearch/snapshot
network.host: 0.0.0.0
http.port: 49200
transport.tcp.port: 49300
#gateway.recover_after_time默認是5分鍾，增大后，減少數據來回拷貝幾率
gateway.recover_after_time: 10m
#舊版本是discovery.zen.ping.unicast.hosts
discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
#[3個節點，就寫2，多於3個，就(總數/2 + 1)]
discovery.zen.minimum_master_nodes: 2
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12