Elasticsearch系列—生產集群部署(下)

2{icon} {views}

概要

本篇繼續講解Elasticsearch集群部署的細節問題

集群重啟問題

如果我們的Elasticsearch集群做了一些離線的維護操作時,如擴容磁盤,升級版本等,需要對集群進行啟動,節點數較多時,從第一個節點開始啟動,到最後一個節點啟動完成,耗時可能較長,有時候還可能出現某幾個節點因故障無法啟動,排查問題、修復故障后才能加入到集群中,此時集群會幹什麼呢?

假設10個節點的集群,每個節點有1個shard,升級后重啟節點,結果有3台節點因故障未能啟動,需要耗費時間排查故障,如下圖所示:

整個過程步驟如下:

  1. 集群已完成master選舉(node6),master發現未加入集群的node1、node2、node3包含的shard丟失,便立即發出shard恢復的指令。

  2. 在線的7台node,將其中一個replica shard升級為primary shard,並且進行為這些primary shard複製足夠的replica shard。

  3. 執行shard rebalance操作。

  4. 故障的3台節點已排除,啟動成功后加入集群。

  5. 這3台節點發現自己的shard已經在集群中的其他節點上了,便刪除本地的shard數據。

  6. master發現新的3台node沒有shard數據,重新執行一次shard rebalance操作。

這個過程可以發現,多做了四次IO操作,shard複製,shard首次移動,shard本地刪除,shard再次移動,這樣憑空造成大量的IO壓力,如果數據量是TB級別的,那費時費力不討好。

出現此類問題的原因是節點啟動的間隔時間不能確定,並且節點越多,這個問題越容易出現,如果可以設置集群等待多少個節點啟動后,再決定是否對shard進行移動,這樣IO壓力就能小很多。

針對這個問題,我們有下面幾個參數:

  • gateway.recover_after_nodes:集群必須要有多少個節點時,才開始做shard恢復操作。
  • gateway.expected_nodes: 集群應該有多少個節點
  • gateway.recover_after_time: 集群啟動后等待的shard恢復時間

如上面的案例,我們可以這樣設置:

gateway.recover_after_nodes: 8
gateway.expected_nodes: 10
gateway.recover_after_time: 5m

這三個參數的含義:集群總共有10個節點,必須要有8個節點加入集群時,才允許執行shard恢復操作,如果10個節點未全部啟動成功,最長的等待時間為5分鐘。

這幾個參數的值可以根據實際的集群規模來設置,並且只能在elasticsearch.yml文件里設置,沒有動態修改的入口。

上面的參數設置合理的情況,集群啟動是沒有shard移動的現象,這樣集群啟動的時候就可以由之前的幾小時,變成幾秒鐘。

JVM和Thread Pool設置

一提到JVM的調優,大家都有手癢的感覺,好幾百個JVM參數,說不定開啟了正確的按鈕,從此ES踏上高性能、高吞吐量的道路。現實情況可能是我們想多了,ES的大部分參數是經過反覆論證的,基本上不用咱們太操心。

JVM GC

Elasticsearch默認使用的垃圾回收器是CMS。

## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

CMS回收器是併發式的回收器,能夠跟應用程序工作線程併發工作,最大程度減少垃圾回收時的服務停頓時間。

CMS還是會有兩個停頓階段,同時在回收特別大的heap時也會有一些問題。儘管有一些缺點,但是CMS對於要求低延時請求響應的軟件來說,還是最佳的垃圾回收器,因此官方的推薦就是使用CMS垃圾回收器。

有一種最新的垃圾回收器叫做G1。G1回收器可以比CMS提供更少的回收停頓時間,而且能夠這對大heap有更好的回收表現。它會將heap劃分為多個region,然後自動預測哪個region會有最多可以回收的空間。通過回收那些region,就可以最小化停頓時長,而且可以針對大heap進行回收。

聽起來還挺好的,只是G1還是比較年輕的一種垃圾回收器,而且經常會發現一些新的bug,這些bug可能會導致jvm掛掉。穩定起見,暫時不用G1,等G1成熟后ES官方推薦后再用不遲。

線程池

我們開發Java應用系統時,對系統調優的一個常見手段就是調整線程池,但在ES中,默認的threadpool設置是非常合理的,對於所有的threadpool來說,除了搜索的線程池,都是線程數量設置的跟cpu core一樣多的。如果我們有8個cpu core,那麼就可以并行運行8個線程。那麼對於大部分的線程池來說,分配8個線程就是最合理的數量。

搜索會有一個更加大的threadpool,線程數量一般被配置為:cpu core * 3 / 2 + 1。

Elasticsearch的線程池分成兩種:接受請求的線程和處理磁盤IO操作的線程,前面那種由ES管理,后一種由Lucene管理,它們之間會進行協作,ES的線程不會因為IO操作而block住,所以ES的線程設置跟CPU核數一樣或略大於CPU核數即可。

服務器的計算能力是非常有限的,線程池的數量過大會導致上下文頻繁切換,更費資源,如果threadpool大小設置為50,100,甚至500,會導致CPU資源利用率很低,性能反而下降。

只需要記住:用默認的線程池,如果真要修改,以CPU核數為準。

heap內存設置最佳實踐

Elasticsearch默認的jvm heap內存大小是2G,如果是研發環境,我會改成512MB,但在生產環境2GB有點少。

在config/jvm.options文件下,可以看到heap的設置:

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space

-Xms2g
-Xmx2g

分配規則

Elasticsearch使用內存主要有兩個大戶:jvm heap和lucene,前者ES用來存放很多數據結構來提供更快的操作性能,後者使用os cache緩存索引文件,包括倒排索引、正排索引,os cache內存是否充足,直接影響查詢檢索的性能。

一般的分配規則是:jvm heap佔用小於一半的內存,剩下的全歸lucene使用。

如果單台機器總內存64GB,那麼heap頂格內存分配為32GB,因為32GB內存以下,jvm會使用compressed oops來解決object pointer耗費過大空間的問題,超過32GB后,jvm的compressed oops功能關閉,這樣就只能使用64位的object pointer,會耗費更多的空間,過大的object pointer還會在cpu,main memory和LLC、L1等多級緩存間移動數據的時候,吃掉更多的帶寬。最終的結果可能是50GB內存的效果和32GB一樣,白白浪費了十幾GB內存。

這裏涉及到jvm的object pointer指針壓縮技術,有興趣可以單獨了解一下。

如果單台機器總內存小於64GB,一般heap分配為總內存的一半即可,具體要看預估的數據量是多少。

如果使用超級機器,1TB內存的那種,官網不建議上那麼牛逼的機器,建議分配4-32GB內存給heap,其他的全部用來做os cache,這樣數據量全部緩存在內存中,不落盤查詢,性能杠杠滴。

最佳實踐建議

  1. 將heap的最小值和最大值設置為一樣大。
  2. elasticsearch jvm heap設置得越大,就有越多的內存用來進行緩存,但是過大的jvm heap可能會導致長時間的gc停頓。
  3. jvm heap size的最大值不要超過物理內存的50%,才能給lucene的file system cache留下足夠的內存。
  4. jvm heap size設置不要超過32GB,否則jvm無法啟用compressed oops,將對象指針進行壓縮,確認日誌里有[node-1] heap size [1007.3mb], compressed ordinary object pointers [true] 字樣出現。
  5. 最佳實踐數據:heap size設置的小於zero-based compressed ooops,也就是26GB,但是有時也可以是30GB。通過-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode開啟對應,確認有heap address: 0x00000000e0000000, size: 27648 MB, Compressed Oops mode: 32-bit字樣,而不是heap address: 0x00000000f4000000, size: 28672 MB, Compressed Oops with base: 0x00000000f3ff0000字樣。

swapping問題

部署Elasticsearch的服務盡可能關閉到swap,如果內存緩存到磁盤上,那查詢效率會由微秒級降到毫秒級,會造成性能急劇下降的隱患。

關閉辦法:

  1. Linux系統執行 swapoff -a 關閉swap,或在/etc/fstab文件中配置。

  2. elasticsearch.yml中可以設置:bootstrap.mlockall: true 鎖住自己的內存不被swap到磁盤上。

使用命令 GET _nodes?filter_path=**.mlockall 可以查看是否開啟mlockall
響應信息:

{
  "nodes": {
    "A1s1uus7TpuDSiT4xFLOoQ": {
      "process": {
        "mlockall": true
      }
    }
  }
}

Elasticsearch啟動的幾個問題

  1. root用戶啟動實例的問題
    如果你用root用戶啟動Elasticsearch的實例,將得到如下的錯誤提示:
org.elasticsearch.bootstrap.StartupException: java.lang.RuntimeException: can not run elasticsearch as root
	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:140) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:127) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) ~[elasticsearch-cli-6.3.1.jar:6.3.1]
	at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-cli-6.3.1.jar:6.3.1]
	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:93) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:86) ~[elasticsearch-6.3.1.jar:6.3.1]
Caused by: java.lang.RuntimeException: can not run elasticsearch as root
	at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:104) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:171) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:326) ~[elasticsearch-6.3.1.jar:6.3.1]
	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:136) ~[elasticsearch-6.3.1.jar:6.3.1]
	... 6 more

無它,建立一個用戶,專門用來啟動Elasticsearch的,如esuser,相應的系統目錄和數據存儲目錄都賦予esuser賬戶為歸屬者。

  1. 啟動時提示elasticsearch process is too low,並且無法啟動成功

完整的提示信息:

max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
memory locking requested for elasticsearch process but memory is not locked

解決辦法:設置系統參數,命令行中的esuser為建立的Linux用戶。

[root@elasticsearch01 bin]# vi /etc/security/limits.conf

# 在文件最後添加
esuser hard nofile 65536
esuser soft nofile 65536
esuser soft memlock unlimited
esuser hard memlock unlimited

設置完成后,可以通過命令查看結果:

# 請求命令
GET _nodes/stats/process?filter_path=**.max_file_descriptors

# 響應結果
{
  "nodes": {
    "A1s1uus7TpuDSiT4xFLOoQ": {
      "process": {
        "max_file_descriptors": 65536
      }
    }
  }
}
  1. 提示vm.max_map_count [65530] is too low錯誤,無法啟動實例

完整的提示信息:

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

解決辦法:添加vm.max_map_count配置項

臨時設置:sysctl -w vm.max_map_count=262144

永久修改:修改vim /etc/sysctl.conf文件,添加vm.max_map_count設置

[root@elasticsearch01 bin]# vim /etc/sysctl.conf

# 在文件最後添加
vm.max_map_count=262144

# 執行命令
[root@elasticsearch01 bin]# sysctl -p

Elasticsearch實例啟停

實例一般使用後台啟動的方式,在ES的bin目錄下執行命令:

[esuser@elasticsearch01 bin]$ nohup ./elasticsearch &
[1] 15544
[esuser@elasticsearch01 bin]$ nohup: 忽略輸入並把輸出追加到"nohup.out"

這個elasticsearch沒有stop參數,停止時使用kill pid命令。

[esuser@elasticsearch01 bin]$ jps | grep Elasticsearch
15544 Elasticsearch
[esuser@elasticsearch01 bin]$ kill -SIGTERM 15544

發送一個SIGTERM信號給elasticsearch進程,可以優雅的關閉實例。

小結

本篇接着上篇的內容,講解了集群重啟時要注意的問題,JVM Heap設置的最佳實踐,以及Elasticsearch實例啟動時常見的問題解決辦法,最後是Elasticsearch優雅關閉的命令。

專註Java高併發、分佈式架構,更多技術乾貨分享與心得,請關注公眾號:Java架構社區
可以掃左邊二維碼添加好友,邀請你加入Java架構社區微信群共同探討技術

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!