點擊上方藍字關注我們
1月11號檢查平臺發現數據采集異常,平臺數據查詢報錯,經核查發現后臺腳本采集程序發生大量kafka連接錯誤,且日志文件一夜漲至200G左右,MySQL主機存儲撐爆,最終導致平臺使用異常。
Kafka后臺報錯大量org.apache.kafka.common.network.Selector異常,查詢資料發現該問題是
socket.request.max.bytes參數值過低導致(默認值為100M),調整到告警值的兩倍后重啟正常。
但隨后在下午發現平臺監控采集數據又中斷了,再次檢查kafka發現有新的報錯信息:
(java.lang.OutOfMemoryError:Java heap space)
這次錯誤比較明顯,內存溢出導致,需要調整kafaka啟動內存,隨即調整了kafka的原生start腳本kafka-server-start.sh加入如下參數:
exportKAFKA_HEAP_OPTS="-Xmx4G –Xms4G"
重啟后發現還是報大量內存溢出,以為是設置過小,就改到了6G,錯誤依舊,ps檢查了一下kakfka進程,發下啟動內存寫的是默認的1G!這里遇上了一個坑,kafka的start腳本其實是調用bin目錄下的/kafka-run-class.sh腳本,而該腳本也設置了啟動內存,所以內存參數一直未生效。
最后注釋該參數,在kafka-server-start.sh加入該參數重啟后恢復正常(附上設置參數如下)
export KAFKA_HEAP_OPTS="-Xmx6G -Xms6G -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80"
回想整個事故原因,是kafka異常導致數據采集進程異常而出現大量錯誤日志,以至于撐爆MySQL主機存儲。而kafaka在最近以來也未做變更,隨即想到最近新增大量數據作處理,新建的topic在每分鐘有大量數據消費,但分區數量也有12個,請教長研的景書大師后,了解到這種情況可以調整topic數據保留時間,緩解數據量過大導致內存溢出的問題,而默認topic的數據保留時間為24h。最后修改了topic保留時間為12小時(網上有大量的修改方法,就不附上在此了)、啟動內存以及調整socket.request.max.bytes參數后,算是給kakfa上了雙保險,集群故障解除。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/130022.html
摘要:而在服務器中應該充分利用多線程來處理執行邏輯。能保證所在的失效,該消息仍然可以從新選舉的中獲取,不會造成消息丟失。這意味著無需等待來自的確認而繼續發送下一批消息。 showImg(https://segmentfault.com/img/remote/1460000018373147?w=702&h=369); 1.概述 Apache Kafka最早是由LinkedIn開源出來的分布式...
摘要:二基于的優先級隊列方案針對以上場景,個推基于設計了第一版的優先級隊列方案。架構在該方案中,個推將優先級統一設定為高中低三個級別。六總結現在個推針對優先級中間件的改造方案已經在部分現網業務中試運行,對于的穩定性,我們還在持續關注中。 showImg(https://segmentfault.com/img/remote/1460000018868129);作者:個推平臺研發工程師 祥子 ...
摘要:歸根到底,高可用性就意味著更少的宕機時間。首先,可以盡量避免應用宕機來減少宕機時間。降低平均失效時間我們對系統變更缺少管理是所有導致宕機事件中最普遍的原因。 我們之前了解了復制、擴展性,接下來就讓我們來了解可用性。歸根到底,高可用性就意味著 更少的宕機時間。 老規矩,討論一個名詞,首先要給它下個定義,那么什么是可用性? 1 什么是可用性 我們常見的可用性通常以百分比表示,這本身就有其隱...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20