在前兩次集群擴(kuò)容的過(guò)程中蹄衷，總是會(huì)出現(xiàn)Too many open files in system問(wèn)題涩搓。對(duì)于這個(gè)問(wèn)題他挎，困擾了一段時(shí)間萍膛。由于elasticsearch在非root用戶下運(yùn)行，開(kāi)始以為只需要調(diào)整limit.conf中的句柄數(shù)配置就好擅羞。但是在我的句柄數(shù)已經(jīng)調(diào)到655350之后尸变，還出現(xiàn)這個(gè)問(wèn)題。我通過(guò)檢查 lsof 命令發(fā)現(xiàn)單個(gè)節(jié)點(diǎn)的句柄數(shù)并不在一個(gè)數(shù)量級(jí)减俏。
如上圖所示召烂。
現(xiàn)在證明造成打開(kāi)文件過(guò)多的問(wèn)題的思路并非局限在limit配置。還需要考慮elasticsearch何時(shí)會(huì)創(chuàng)建大批量的文件娃承？
仔細(xì)查看了elasticsearch文檔奏夫，發(fā)現(xiàn)如下描述：
由于自動(dòng)刷新流程每秒會(huì)創(chuàng)建一個(gè)新的段，這樣會(huì)導(dǎo)致短時(shí)間內(nèi)的段數(shù)量暴增历筝。而段數(shù)目太多會(huì)帶來(lái)較大的麻煩酗昼。 每一個(gè)段都會(huì)消耗文件句柄、內(nèi)存和cpu運(yùn)行周期梳猪。更重要的是麻削，每個(gè)搜索請(qǐng)求都必須輪流檢查每個(gè)段；所以段越多春弥，搜索也就越慢呛哟。
Elasticsearch通過(guò)在后臺(tái)進(jìn)行段合并來(lái)解決這個(gè)問(wèn)題。小的段被合并到大的段匿沛，然后這些大的段再被合并到更大的段扫责。
段合并的時(shí)候會(huì)將那些舊的已刪除文檔從文件系統(tǒng)中清除。被刪除的文檔（或被更新文檔的舊版本）不會(huì)被拷貝到新的大段中逃呼。
過(guò)程如下圖：
瑣碎的段會(huì)自動(dòng)合并為一個(gè)大段鳖孤，在新的大段被創(chuàng)建完成并flash之后者娱，舊的段會(huì)被刪除。
因此苏揣，這就解釋了“Too many open files in system”問(wèn)題出現(xiàn)的原因：
在系統(tǒng)擴(kuò)容的過(guò)程中黄鳍，會(huì)有大量的數(shù)據(jù)被平衡到新的節(jié)點(diǎn)，這樣會(huì)消耗大量的IO腿准，同時(shí)际起，elk集群中的新數(shù)據(jù)拾碌，由于沒(méi)有對(duì)數(shù)據(jù)節(jié)點(diǎn)做冷熱區(qū)分吐葱，會(huì)源源不斷的寫(xiě)入到新節(jié)點(diǎn)，這就造成了新節(jié)點(diǎn)中的段會(huì)非常多校翔，舊的段無(wú)法合并弟跑，新的數(shù)據(jù)又在源源不斷的寫(xiě)入，這就造成了文件數(shù)會(huì)越來(lái)越多防症，因此出現(xiàn)了上述問(wèn)題孟辑。
要想徹底解決上述問(wèn)題，只有一個(gè)辦法蔫敲，那就是定期對(duì)段進(jìn)行合并饲嗽。elk官方建議段的數(shù)量是一個(gè)分片只有一個(gè)。
可以通過(guò)如下api進(jìn)行設(shè)置：
POST /{indexname}/_forcemerge?max_num_segments=1
還支持通配符：
POST /applog-prod-2016.12.*/_forcemerge?max_num_segments=1
可以通過(guò)如下API查看索引的段信息：
GET applog-prod-2016.11.30*/_segments
如下是段合并的效果：
總結(jié)：
1.需要對(duì)elasticsearch制定冷/熱策略奈嘿，將節(jié)點(diǎn)分為存放歷史數(shù)據(jù)的冷節(jié)點(diǎn)貌虾，和存放實(shí)時(shí)數(shù)據(jù)的熱節(jié)點(diǎn)。
2.需要定時(shí)對(duì)冷數(shù)據(jù)進(jìn)行段合并裙犹。
