0x00 問題出現

前段時間，kudu叢集寫操作出現問題，記憶體不足，造成所有往kudu寫入資料的任務失敗。

主要錯誤資訊：Service unavailable: Soft memory limit exceeded (at 98.71% of capacity)

此時kudu叢集的io偏高，kudu限制的記憶體使用率95%以上。kudu寫資料會先寫到記憶體裡，再刷到磁碟上。

記憶體調大了20%，重啟kudu之後，記憶體降下來了，io繼續升高。看日誌發現此時正在啟動tablet，和重新整理資料，所以io會很高，但此時某些kudu表是不能用的。

重啟是萬能的，調大記憶體也是萬能的，問題暫時解決。
到第二天凌晨，問題又出現了，記憶體不足，往kudu寫資料的任務失敗。

那就再調大記憶體！！！！！

0x01 進行處理

優化前的一些引數：
memory_limit_hard_bytes單臺機器最高記憶體 :54G;
default_num_replicas副本數 :5;
maintenance_manager_num_threads維護管理器執行緒 :8;
block_cache_capacity_mb 快取容量 :4G;

官網給出了記憶體不足的解決建議：

1. 如果主機有更多的記憶體可供Kudu使用，請增加——memory_limit_hard_bytes。

2. 通過增加磁碟數量或增加維護管理器執行緒(maintenance_manager_num_threads)的數量，
提高Kudu從記憶體到磁碟的寫入速度。通常，維護管理器執行緒與資料目錄的推薦比例是1:3。

3. 在應用程式端減少流向Kudu的寫量。

檢查block_cache_capacity_mb的值。這個設定決定了Kudu塊快取的最大大小。
雖然較高的值有助於提高讀寫效能，但設定過高(作為-memory_limit_hard_bytes的百分比)是有害的。

 

我們調整的引數：

1. 單臺機器分配給kudu最高記憶體96G
2. 副本數改為3（減少磁碟io）
3. 維護管理器執行緒改為4，與單臺機器的資料目錄個數成1：3比例（我們資料目錄12個）；
4. block_cache_capacity_mb由4G調整至512M

0x02 總之

這次問題根本原因還是寫入資料量增大，記憶體不夠。

總之，會有磁碟io瓶頸，如果有條件儘量使用ssd硬碟，或者從犧牲記憶體，容錯，時間等方面來平衡磁碟io帶來的效能瓶頸。