建站
咨詢
售后
建站咨詢
新聞中心
提到Elasticsearch，讓筆者最惡心的倒不是它的反人類的DSL設(shè)計(jì)，而是每次安裝都需要修改進(jìn)程的最大文件描述符。那ES與文件描述符有啥恩怨呢，下面就來嘮叨嘮叨。首先說說文件描述符、在說說ES為什么要這么多文件描述符。
一、文件描述符
1、什么是文件描述符
文件描述符（File descriptor）是操作系統(tǒng)為了高效管理文件所創(chuàng)建的一種索引，用于指向被打開的文件，所有I/O操作都是通過文件描述符來實(shí)現(xiàn)。有的地方也會說成是文件句柄，他倆有些區(qū)別，這里為了方便理解，暫且認(rèn)為一樣。
如果以文件句柄（File Handle）來理解的話，也很形象。Handle是門把手的意思，我們用門把手操作門，類似的，進(jìn)程用文件句柄操作底層操作系統(tǒng)的資源。
在Linux中，遵循一切皆是文件的原則，磁盤文件、目錄、設(shè)備、網(wǎng)絡(luò)套接字、硬件等都是文件。當(dāng)進(jìn)程讀寫文件，在打開時(shí)，文件和進(jìn)程就建立了連接，文件描述符就是這個(gè)連接。
文件描述符實(shí)際上就是對內(nèi)核層的一個(gè)硬件資源實(shí)例的指針的引用。當(dāng)然啦，它和指針也是有區(qū)別的，指針是棧上的變量，用來操作堆內(nèi)存里的對象。
文件描述符在系統(tǒng)里的位置見下圖：
2、為什么需要文件描述符
這里還用門把手舉例。一扇門如果有多個(gè)把手，被不同的人操作，那門往哪兒走就不確定了，很容易出現(xiàn)爭論。為了避免這種情況，門只有一個(gè)把手。
為了解決系統(tǒng)資源浪費(fèi)和資源沖突的問題，操作系統(tǒng)不會讓每個(gè)用戶層的進(jìn)程都在內(nèi)核層創(chuàng)建一個(gè)硬件資源實(shí)例。在操作同一個(gè)系統(tǒng)硬件資源時(shí)，用戶層可能有多個(gè)進(jìn)程，但是都對應(yīng)到內(nèi)核層的一個(gè)進(jìn)程。
3、文件描述符數(shù)量限制
操作系統(tǒng)會為進(jìn)程設(shè)置一個(gè)默認(rèn)的可以操作的文件描述符數(shù)量，進(jìn)程打開的文件數(shù)量或者需要的文件數(shù)量超過這個(gè)數(shù)字時(shí)就會拋出異常。
通過ulimit -a命令可以查看可操作的文件描述符數(shù)量。通過vim /etc/security/limits.con可以修改進(jìn)程可操作性的文件描述符數(shù)量。
二、ES為什么要這么多文件描述符
在說ES為什么要這么多文件描述符之前，先簡單說說ES寫入數(shù)據(jù)的過程。
1.ES寫入數(shù)據(jù)的過程
(1) 寫入的主要流程
假設(shè)有3個(gè)節(jié)點(diǎn)：node1、node2、node3，其中node2是主節(jié)點(diǎn)，寫入數(shù)據(jù)的主要流程如下：
- 客戶端的請求攜帶數(shù)據(jù)，到達(dá)node1，node1找到主分片所在的node2。
- node1將數(shù)據(jù)轉(zhuǎn)發(fā)到主分片所在node2，node2將數(shù)據(jù)寫入主分片。
- 主分片寫入成功后，node2將數(shù)據(jù)轉(zhuǎn)發(fā)到node1和node3，node1和node3將數(shù)據(jù)寫入副本分片。
- 所有副本分片都寫入成功后，node2向 客戶端所請求的節(jié)點(diǎn)node1 返回寫入成功的消息。
- 客戶端所請求的節(jié)點(diǎn)node1向客戶端返回成功。
(2) 寫入的細(xì)節(jié)流程
ES寫入數(shù)據(jù)的細(xì)節(jié)流程分為4步：Refresh操作、寫Transaction Log、Flush操作、Merge操作。
- Refresh操作：在文檔寫入ES時(shí)首先會寫到Index Buffer里，然后每隔一秒執(zhí)行一次Refresh操作，把Index Buffer里的數(shù)據(jù)寫入磁盤緩存里，但不會調(diào)用fsync刷到硬盤。因?yàn)閿?shù)據(jù)被Refresh 后才能被檢索出來，所以ES是近實(shí)時(shí)的搜索引擎。
- 寫Transaction Log：文檔寫入到Index Buffer后，數(shù)據(jù)是沒有刷到硬盤的，存在數(shù)據(jù)丟失的風(fēng)險(xiǎn)。為了保證數(shù)據(jù)不丟失，在寫完 Index Buffer 后，系統(tǒng)還要寫Transaction Log，寫Transaction Log默認(rèn)是調(diào)用 fsync 進(jìn)行刷盤的。ES重啟時(shí)會從Transaction Log中恢復(fù)數(shù)據(jù)，防止數(shù)據(jù)丟失。
- Flush操作：Flush操作會將磁盤緩存持久化到磁盤中，默認(rèn)30分鐘 或 在Transaction Log寫滿時(shí)觸發(fā)。Flush將磁盤緩存 持久化到磁盤后，會清空Transaction Log。
- Merge操作：在每次Refresh 后都會創(chuàng)建一個(gè)新的Segment文件，隨著時(shí)間推移和索引越來越多，Segment文件會暴增，這時(shí)會帶來許多問題，比如消耗過多的文件描述符、內(nèi)存、CPU時(shí)間周期等，而且每次搜索都要檢查每個(gè)Segment然后再合并結(jié)果，所以Segment越多、搜索也就越慢，因此需要合并Segment。ES會自動執(zhí)行Merge操作，然后物理刪除過多的Segment文件。
2、為什么要這么多文件描述符
通過以上ES寫數(shù)據(jù)的流程可以知道，ES在每次Refresh時(shí)都會創(chuàng)建新的Segment，創(chuàng)建索引的過程中會創(chuàng)建大量的Segment。Segment內(nèi)部一般包含著：詞項(xiàng)、詞頻、文檔之間的關(guān)系。每個(gè)Segment都是一個(gè)文件，ES使用了大量的文件。每一個(gè)Segment都會消耗文件描述符、內(nèi)存和CPU運(yùn)行周期。同時(shí)，ES 在節(jié)點(diǎn)之間進(jìn)行通信和數(shù)據(jù)拷貝、ES在和客戶端之間進(jìn)行通信等，也使用了大量的網(wǎng)絡(luò)資源。
基于以上原因，ES需要大量的文件描述符。Linux 系統(tǒng)為進(jìn)程準(zhǔn)備了一個(gè)默認(rèn)的文件描述符數(shù)量，但是這對ES節(jié)點(diǎn)來說有點(diǎn)低了，所以要調(diào)大文件描述符數(shù)量。
3、Linux命令lsof
lsof命令是Linux系統(tǒng)管理工具，人如其名，“列出打開文件（lists openfiles）”。
lsof -p pid命令：顯示系統(tǒng)中某個(gè)進(jìn)程當(dāng)前已打開的所有文件列表。
執(zhí)行l(wèi)sof -p 29624時(shí)，可以看到大量的文件，索引越多，寫入的數(shù)據(jù)越多，文件描述符數(shù)量越多。
執(zhí)行l(wèi)sof -p 29624|wc -l，可以查看進(jìn)程打開文件的總數(shù)。
4、其余的文件描述符不夠用的情況
大量新的數(shù)據(jù)源源不斷的快速寫入到ES，造成臨時(shí)的Segment文件越來越多，ES無法快速合并成一個(gè)大的Segment。在查詢時(shí)，如果查詢的數(shù)據(jù)對應(yīng)到多個(gè)Segment，那么打開的文件描述符就很多了。
機(jī)器內(nèi)存過小，資源緊張時(shí)內(nèi)存不夠，會觸發(fā)OOM-Killer將ES進(jìn)程殺死，其實(shí)是一種假死的，因?yàn)檫M(jìn)程被Kill掉之后，保活進(jìn)程又會將ES重啟，而每次重啟后都會產(chǎn)生新的translog文件，并且沒有把之前舊的日志文件刪除，最終把系統(tǒng)的文件描述符耗盡。
如果還有其余場景的話，歡迎朋友們在留言區(qū)補(bǔ)充。
三、總結(jié)
本文主要說了 文件描述符 和 ES為什么要這么多文件描述符，希望對你有幫助，核心概念如下：
- 文件描述符：用戶層的進(jìn)程 對 內(nèi)核層一個(gè) 硬件資源實(shí)例 的指針 的引用。
- ES寫入流程：Refresh操作、寫Transaction Log、Flush操作、Merge操作。
- 為什么要這么多：ES在每次Refresh時(shí)都會創(chuàng)建新的Segment，隨著時(shí)間的推移和索引的增多，會導(dǎo)致短時(shí)間內(nèi)的Segment數(shù)量暴增。ES 在節(jié)點(diǎn)之間進(jìn)行通信和數(shù)據(jù)拷貝、ES在和客戶端之間進(jìn)行通信等原因，所以需要大量的文件描述符。
網(wǎng)頁名稱：Elasticsearch與文件描述符的恩恩怨怨
轉(zhuǎn)載來源：http://www.5511xx.com/article/dpoiijj.html
