目錄
1.ELK優化
2.優化 ES 索引設置
2.1?優化 fsync
2.2?優化 refresh
2.3?優化 merge
2.4?優化設置
2.5?打開索引
3.優化線程池配置
3.1?優化的方案
4.鎖定內存，不讓 JVM 使用 Swap
5.減少分片數、副本數
6.ES優化總結
1.ELK優化
ELK優化可以圍繞著 linux內核優化、JVM優化、ES配置優化、架構優化（filebeat/fluentd代替logstash、加入kafka做消息隊列）來實現。
ES 作為日志存儲時的特性是：高并發寫、讀少、接受 30 秒內的延時、可容忍部分日志數據丟失。
2.優化 ES 索引設置
2.1?優化 fsync
為了保證不丟失數據，就要保護 translog 文件的安全:
Elasticsearch 2.0 之后，每次寫請求(如 index 、delete、update、bulk 等)完成時，都會觸發fsync將 translog 中的 segment 刷到磁盤，然后才會返回 200 OK 的響應；或者: 默認每隔5s就將 translog 中的數據通過fsync強制刷新到磁盤。
該方式提高數據安全性的同時，降低了一點性能。
==> 頻繁地執行 fsync 操作，可能會產生阻塞導致部分操作耗時較久。 如果允許部分數據丟失，可設置異步刷新 translog 來提高效率，還有降低 flush 的閥值， 優化如下：
"index.translog.durability": "async",
"index.translog.flush_threshold_size":"1024mb",
"index.translog.sync_interval": "120s"
2.2?優化 refresh
寫入 Lucene 的數據，并不是實時可搜索的，ES 必須通過 refresh 的過程把內存中的數據轉換成 Lucene 的完整 segment 后，才可以被搜索。
默認 1 秒后，寫入的數據可以很快被查詢到，但勢必會產生大量的 segment，檢索性能會受到影響。所以，加大時長可以降低系統開銷。 對于日志搜索來說，實時性要求不是那么高，設置為 5 秒或者 10s；對于 SkyWalking，實時性要求更低一些，我們可以設置為 30s。
設置如下：
"index.refresh_interval":"5s
2.3?優化 merge
index.merge.scheduler.max_thread_count 控制并發的 merge 線程數，如果存儲是并發性能較好的 SSD，可以用系統默認的 max(1, min(4, availableProcessors / 2))，當節點配置的 cpu 核數較高時，merge 占用的資源可能會偏高，影響集群的性能，普通磁盤的話設為1，發生磁盤 IO 堵塞。設置 max_thread_count 后，會有 max_thread_count + 2 個線程同時進行磁盤操作，也就是設置為 1 允許 3 個線程。
設置如下：
"index.merge.scheduler.max_thread_count":"1"
2.4?優化設置
# 需要先 close 索引，然后再執行，最后成功之后再打開
# 關閉索引
curl -XPOST 'http://localhost:9200/_all/_close'# 修改索引設置
curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{"index.merge.scheduler.max_thread_count" : "1","index.refresh_interval" : "10s","index.translog.durability" : "async","index.translog.flush_threshold_size":"1024mb","index.translog.sync_interval" : "120s"}'
2.5?打開索引
curl -XPOST 'http://localhost:9200/_all/_open'
3.優化線程池配置
- write 線程池滿負荷，導致拒絕任務，而有的數據無法寫入。而經過上面的優化后，拒絕的情況少了很多，但是還是有拒絕任務的情況。所以我們還需要優化 write 線程池。
- write 線程池采用 fixed 類型的線程池，也就是核心線程數與最大線程數值相同。線程數默認等于 cpu 核數，可設置的最大值只能是 cpu 核數加 1，比如 16 核的 CPU， 能設置的線程數最大值為 17。
3.1?優化的方案
●線程數改為 17，也就是 cpu 總核數加 1
●隊列容量加大。隊列在此時的作用是消峰。不過隊列容量加大本身不會提升處理速度，只是起到緩沖作用。此外，隊列容量也不能太大，否則積壓很多任務時會占用過多堆內存。修改 elasticsearch.yml 文件增加配置
# 線程數設置
thread_pool:
? write:
? ? # 線程數默認等于cpu核數，即16 ?
? ? size: 17
? ? # 因為任務多時存在任務拒絕的情況，所以加大隊列大小，可以在間歇性任務量陡增的情況下，緩存任務在隊列，等高峰過去逐步消費完。
? ? queue_size: 10000
4.鎖定內存，不讓 JVM 使用 Swap
- Swap交換分區：當系統的物理內存不夠用的時候，就需要將物理內存中的一部分空間釋放出來，以供當前運行的程序使用。那些被釋放的空間可能來自一些很長時間沒有什么操作的程序，這些被釋放的空間被臨時保存到 Swap 中，等到那些程序要運行時，再從 Swap 中恢復保存的數據到內存中。這樣，系統總是在物理內存不夠時，才進行 Swap 交換。
- Swap 交換分區對性能和節點穩定性非常不利，一定要禁用。它會導致垃圾回收持續幾分鐘而不是幾毫秒，并會導致節點響應緩慢，甚至與集群斷開連接。
?
有三種方式可以實現 ES 不使用 Swap 分區
（1）Linux 系統中的關閉 Swap (臨時有效)
執行命令 sudo swapoff -a
可以臨時禁用 Swap 內存，但是操作系統重啟后失效
（2）Linux 系統中的盡可能減少 Swap 的使用(永久有效)
執行下列命令
echo "vm.swappiness = 1" >> /etc/sysctl.conf
正常情況下不會使用 Swap，除非緊急情況下才會 Swap。
（3）啟用 bootstrap.memory_lock
config/elasticsearch.yml 文件增加配置
#鎖定內存，不讓 JVM 寫入 Swap，避免降低 ES 的性能
bootstrap.memory_lock: true
5.減少分片數、副本數
（1）分片
索引的大小取決于分片與段的大小，分片過小，可能導致段過小，進而導致開銷增加；分片過大可能導致分片頻繁 Merge，產生大量 IO 操作，影響寫入性能。
因為我們每個索引的大小在 15G 以下，而默認是 5 個分片，沒有必要這么多，所以調整為 3 個。
"index.number_of_shards": "3"
（2）副本數
減少集群副本分片數，過多副本會導致 ES 內部寫擴大。副本數默認為 1，如果某索引所在的 1 個節點宕機，擁有副本的另一臺機器擁有索引備份數據，可以讓索引數據正常使用。但是數據寫入副本會影響寫入性能。對于日志數據，有 1 個副本即可。 對于大數據量的索引，可以設置副本數為 0，減少對性能的影響。
"index.number_of_replicas": "1"
6.ES優化總結
(1）對索引進行優化：
優化fsync，適當加大刷盤間隔時間（index.translog.sync_interval，默認值為5s，可調整為30s或60s）
優化refresh，適當加大把內存數據寫入Lucene的間隔時間（index.refresh_interval，默認值為1s，可調整為5s或10s）
優化merge，根據硬盤的性能適當調整merge的線程數（index.merge.scheduler.max_thread_count，默認值為max，可調整為1，設置為1可允許最多3個并發的merge線程數）
(2）優化write線程池配置，減少拒絕任務的情況：修改ES配置文件elasticsearch.yml，設置write線程為 CPU核數+1?
(3）鎖定內存，不讓ES使用swap：swapoff -a ，關閉swap
修改內核參數 vm.swappiness=1，使系統盡量不使用swap
?修改ES配置文件：bootstrap.memory_lock: true ，啟動ES鎖定內存
(4）適當的減少索引的分片數、副本數
分片數：index.number_of_shards，默認值為5，索引大小較小時，可調整分片數為3
副本數：index.number_of_replicas，默認值為1，即每個索引會有一份額外的副本數據，對于日志數據不需要太高的安全性，有1個副本即可，所以可調整副本數為0
