提到Elasticsearch,讓筆者最惡心的倒不是它的反人類的DSL設計,而是每次安裝都需要修改進程的最大文件描述符。那ES與文件描述符有啥恩怨呢,下面就來嘮叨嘮叨。首先說說文件描述符、在說說ES為什么要這么多文件描述符。
文件描述符(File descriptor)是操作系統為了高效管理文件所創建的一種索引,用于指向被打開的文件,所有I/O操作都是通過文件描述符來實現。有的地方也會說成是文件句柄,他倆有些區別,這里為了方便理解,暫且認為一樣。
如果以文件句柄(File Handle)來理解的話,也很形象。Handle是門把手的意思,我們用門把手操作門,類似的,進程用文件句柄操作底層操作系統的資源。
在Linux中,遵循一切皆是文件的原則,磁盤文件、目錄、設備、網絡套接字、硬件等都是文件。當進程讀寫文件,在打開時,文件和進程就建立了連接,文件描述符就是這個連接。
文件描述符實際上就是對內核層的一個硬件資源實例的指針的引用。當然啦,它和指針也是有區別的,指針是棧上的變量,用來操作堆內存里的對象。
文件描述符在系統里的位置見下圖:
這里還用門把手舉例。一扇門如果有多個把手,被不同的人操作,那門往哪兒走就不確定了,很容易出現爭論。為了避免這種情況,門只有一個把手。
為了解決系統資源浪費和資源沖突的問題,操作系統不會讓每個用戶層的進程都在內核層創建一個硬件資源實例。在操作同一個系統硬件資源時,用戶層可能有多個進程,但是都對應到內核層的一個進程。
操作系統會為進程設置一個默認的可以操作的文件描述符數量,進程打開的文件數量或者需要的文件數量超過這個數字時就會拋出異常。
通過ulimit -a命令可以查看可操作的文件描述符數量。通過vim /etc/security/limits.con可以修改進程可操作性的文件描述符數量。
在說ES為什么要這么多文件描述符之前,先簡單說說ES寫入數據的過程。
(1) 寫入的主要流程
假設有3個節點:node1、node2、node3,其中node2是主節點,寫入數據的主要流程如下:
(2) 寫入的細節流程
ES寫入數據的細節流程分為4步:Refresh操作、寫Transaction Log、Flush操作、Merge操作。
通過以上ES寫數據的流程可以知道,ES在每次Refresh時都會創建新的Segment,創建索引的過程中會創建大量的Segment。Segment內部一般包含著:詞項、詞頻、文檔之間的關系。每個Segment都是一個文件,ES使用了大量的文件。每一個Segment都會消耗文件描述符、內存和CPU運行周期。同時,ES 在節點之間進行通信和數據拷貝、ES在和客戶端之間進行通信等,也使用了大量的網絡資源。
基于以上原因,ES需要大量的文件描述符。Linux 系統為進程準備了一個默認的文件描述符數量,但是這對ES節點來說有點低了,所以要調大文件描述符數量。
lsof命令是Linux系統管理工具,人如其名,“列出打開文件(lists openfiles)”。
lsof -p pid命令:顯示系統中某個進程當前已打開的所有文件列表。
執行lsof -p 29624時,可以看到大量的文件,索引越多,寫入的數據越多,文件描述符數量越多。
執行lsof -p 29624|wc -l,可以查看進程打開文件的總數。
大量新的數據源源不斷的快速寫入到ES,造成臨時的Segment文件越來越多,ES無法快速合并成一個大的Segment。在查詢時,如果查詢的數據對應到多個Segment,那么打開的文件描述符就很多了。
機器內存過小,資源緊張時內存不夠,會觸發OOM-Killer將ES進程殺死,其實是一種假死的,因為進程被Kill掉之后,保活進程又會將ES重啟,而每次重啟后都會產生新的translog文件,并且沒有把之前舊的日志文件刪除,最終把系統的文件描述符耗盡。
如果還有其余場景的話,歡迎朋友們在留言區補充。
本文主要說了 文件描述符 和 ES為什么要這么多文件描述符,希望對你有幫助,核心概念如下:
本文鏈接:http://www.www897cc.com/showinfo-26-44372-0.htmlElasticsearch與文件描述符的恩恩怨怨
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 你想不到的 Python 之用
下一篇: 探索 Python中 序列化與反序列化