上一篇文章，記flume部署過程中遇到的問題以及解決方法，記錄了flume在執行過程中遇到的問題的解決方法，本文將記錄在專案除錯過程中對flume效能的優化。
再放上專案的拓撲結構圖：

實際生產環境中，agent層的機器大約有50臺，在高峰時期生成的日誌量大約在5000條/s, 每天總共生成的日誌量大約在8T左右, collector的機器有8臺，所以對該系統的傳輸效率有很高的要求。

在測試中，發現在使用基本配置時，flume傳送資料的效率並不是很理想，agent向collector傳送資料最快也就每秒1000條左右，遠不能滿足系統傳輸需求，在隨後的除錯過程中，通過修改jvm環境引數以及agent、collector層的配置，逐步使得傳輸效能達到要求，現將除錯過程記錄如下：

agent層的除錯資料：

collector層的除錯資料：

agent到collector啟用zlib壓縮前後的網路頻寬情況

由圖可見，在啟用壓縮前，頻寬基本佔用在50M左右，啟用後，頻寬佔用在10M左右

總結：
1、預設jvm環境只使用了20m記憶體，需要調整，擴大到2G基本夠用，不需要過大；
2、collector到kafka，啟用的sink越多，傳輸越快；
3、如果collector到kafka通路受阻，使資料堆積在channel中，如果channel堆滿，則會影響agent到collector的傳輸；
4、agent到collector如果配置了組策略（sink group），則一個組策略只啟動一個傳輸執行緒，多個sink成一組則傳輸效率遠不如sink各傳各的，一個sink相當於一個傳輸執行緒；
5、通路不受阻的情況下，memoryChannel傳輸效率比fileChannel高很多，不過對cpu、記憶體的要求會很高；
6、avro壓縮傳輸對傳輸效率沒有太大提升，反而增大cpu負擔,但是會大大降低網路頻寬；
7、在網路頻寬受限的情況下，增加sink、改用memory channel等方法都不能增加傳輸效率；
8、影響flume傳輸效能的主要因素有，jvm記憶體、網路頻寬、channel型別、sink個數、是否壓縮、機器硬體效能，各條件需要做一個綜合的效能平衡，某一個環節出現瓶頸就會影響整個系統的傳輸效能。

ps：csdn的表格使用起來太蛋疼了…這個表格搞了我整整一個下午加一個晚上…