問題背景與現象
上層元件訪問hdfs緩慢，懷疑hdfs有效能問題。
可能原因
hdfs的儲存的物件數超過namenode配置的記憶體。
原因分析
namenode中檔案物件需要占用一定的記憶體，消耗記憶體大小隨檔案物件的生成而線性遞增。namenode中，檔案物件可以是檔案、目錄或者block。在namenode webui介面的summary也可以看到檔案系統物件（filesystem objects）的統計。
從manager訪問「services > hdfs status > namenode(active) 」的summary 頁面檢視hdfs的「files and directories 」以及「block」的情況。
確認總物件數量是否超過namenode記憶體配置值。namenode記憶體配置參考值和檔案物件數量關係如下
檔案數量
(1檔案對應1block)
檔案系統物件數量（filesystem objects=files+blocks）
參考值
5,000,000
10,000,000
-xms6g -xmx6g -xx:newsize=512m -xx:maxnewsize=512m
10,000,000
20,000,000
-xms12g -xmx12g -xx:newsize=1g -xx:maxnewsize=1g
25,000,000
50,000,000
-xms32g -xmx32g -xx:newsize=3g -xx:maxnewsize=3g
50,000,000
100,000,000
-xms64g -xmx64g -xx:newsize=6g -xx:maxnewsize=6g
100,000,000
200,000,000
-xms96g -xmx96g -xx:newsize=9g -xx:maxnewsize=9g
150,000,000
300,000,000
-xms164g -xmx164g -xx:newsize=12g -xx:maxnewsize=12g
解決辦法
確認並調整namenode記憶體： 如果記憶體配置不合理，需要參考**調整namenode服務端的gc_opts的前4位，並重啟namenode生效（重啟namenode過程中，hdfs服務不可用，需中斷業務）。
調整記憶體需同時調整監控轉告警閾值。 以適應當前namenode記憶體對應的檔案上限。（「調整告警閾值」步驟不會重啟元件，因此不會影響業務）。
說明： 「調整告警閾值」步驟不會重啟元件，因此不會影響業務。
如果無法增加記憶體，可以刪除集群中無用檔案，減少集群中的檔案物件數量。
NameNode啟動中image檔案處理流程
namenode時與image檔案相關的大概有下面三步操作 第一步 載入image namenode啟動後時首先載入硬碟上的fsimage檔案 保持了整個命名空間 和edits檔案 保持了命名空間的操作日誌 在記憶體中merge後將新的fsimage寫到磁碟上，即做一次checkpoint。其中載入...
python 檔案大於記憶體怎麼讀取
最近處理文字文件時 檔案約2gb大小 出現memoryerror錯誤和檔案讀取太慢的問題，後來找到了兩種比較快large file reading 的方法，本文將介紹這兩種讀取方法。我們談到 文字處理 時，我們通常是指處理的內容。python 將文字檔案的內容讀入可以操作的字串變數非常容易。檔案物件...
float存數空間是否大於long的
最為乙個常識，我們都知道浮點型在記憶體中占用的是 4 個位元組的空間，而 long 型占用的是 8 個位元組的空間。可是為什麼 4 個位元組的 float 型的最大值會大於 long 型的最大值呢？我們都知道，float 型別的範圍是 一 3.403e38 3.403e38。而 long 型別的範圍...