問題描述
2018年xx月xx日 下午4點20分左右 xxx無意中看到xxx正在排查線上Kafka集群遇到的問題，隨后問明情況，有一台機器上Kafka進程掛了，當時他正在lark平台上查看錯誤日志信息，隨后我一起加入排查問題。
事故起止時間：2018年xx月xx日 16時30分~2018年9月13日 17時25分
業務影響：理論上無影響，業務自動容錯，生產和消費讀寫失敗重試路由到其他Kafka節點上。
參與處理人：xxx、xxx
處理過程
2018年xx月xx日 16時42分 xxx查看lark日志，分析錯誤日志
2018年xx月xx日 16時48分 xxx登錄Kafka機器10.136.40.2 查看系統參數
2018年xx月xx日 16時55分 xxx整理系統優化參數列表
2018年xx月xx日 17時12分 xxx修改系統參數
2018年xx月xx日 17時25分 xxx通過開源cloudera平台重啟Kafka服務，觀察日志，啟動正常
定位過程
1.查看lark錯誤日志
看到 more Caused by: java.lang.OutOfMemoryError: Map failed at sun.nio.ch.FileChannelImpl.map0(Native Method) 錯誤
登錄上機器(ssh 10.136.40.2)查看：
如上圖不是jvm heap OutofMemoryError報錯，是新創建索引文件做mmap內存映射時報錯，通過判斷分析，很可能是max_map_count數量不足導致的。
google搜索問題原因：https://stackoverflow.com/questions/43042144/kafka-server-failed-to-start-java-io-ioexception-map-failed
基本確定是max_map_count配置過低導致的
查看系統參數配置
[worker@c3-d13-136-40-2 kafka]$ sudo sysctl -a | grep "max_map_count"
vm.max_map_count = 65530
通過Kafka系統參數配置，想到了elastic search啟動前強制配置系統參數，否則啟動報錯
es中vm.max_map_count參數配置
es啟動強制優化的做法，值得借鑒
為什么會出現此次故障
- 1.缺乏完善監控報警系統，無法做到及時預警
- 2.我們對Kafka集群線上運行情況不掌握，不了解
- 3.centos系統未做參數優化
為什么缺乏監控報警系統
- 因為我們的Kafka生態圈處於建設中
為什么Kafka集群線上運行情況不掌握，不了解
- 因為之前對Kafka了解甚少，缺乏對Kafka整體把控和認識
為什么系統未做參數優化
- 因為系統是運維安裝的，我們就直接用了，沒有注意到會有如此影響，對Kafka運行環境要求理解不深刻
max_map_count作用分析
名詞解釋：進程中虛擬內存映射區域的最大數量。
官方解釋：https://www.oschina.net/translate/understanding-virtual-memory?print
max_map_count文件包含限制一個進程可以擁有的VMA(虛擬內存區域)的數量。虛擬內存區域是一個連續的虛擬地址空間區域。在進程的生命周期中，每當程序嘗試在內存中映射文件，鏈接到共享內存段，或者分配堆空間的時候，這些區域將被創建。調優這個值將限制進程可擁有VMA的數量。限制一個進程擁有VMA的總數可能導致應用程序出錯，因為當進程達到了VMA上線但又只能釋放少量的內存給其他的內核進程使用時，操作系統會拋出內存不足的錯誤。如果你的操作系統在NORMAL區域僅占用少量的內存，那么調低這個值可以幫助釋放內存給內核用。
百度質量部分析參考：http://www.10tiao.com/html/473/201606/2651473114/1.html
程序底層調研malloc、直接調用mmap和mprotect和加載共享庫時、java中類FileChannel.map方法都會產生內存映射區域。
Kafka服務使用scala語言開發，運行與jvm平台上，因為jvm heap是預分配的內存，所以占用虛擬虛擬內存區域很少。在Kafka程序中占用最大是做文件映射(調用mmap函數)，Kafka中存儲分為數據文件和索引文件，數據文件直接讀寫不進行mmap映射，而索引文件為了加快讀寫速度就實現了mmap映射機制，每創建一個索引文件做一次虛擬內存映射，map_count數量就加1，直到當前map_count > 系統 max_map_count，就會拋出OutofMemoryError，接着java進程退出了。下面是索引文件做映射的代碼
后續工作
Kafka集群面臨的風險
如果其他節點不進行系統參數優化，Kafka節點可能因為請求高峰或數據傾斜，也有擋掉的風險，所以Kafka集群所有的節點都要進行調整，防患於未然。下面TODO工作。
梳理系統參數列表 列出所有系統優化參數 xxx xx月xx日 DONE
編寫腳本上線執行 提交工單，運維負責執行 xxx xx月xx日 DONE