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