某一個(gè)下午,接口組的小伙伴突然說(shuō)再kibana上看到的消息是7天前的,嚇得我趕緊放下了手中的代碼,直接看生產(chǎn)kafka的消費(fèi)情況,,一看,果然~~~
圖中可以看到 Lag(差值) 每個(gè)partition滯后240w+的消息數(shù)據(jù),這個(gè)topic一共有100個(gè)partition,也就是說(shuō)滯后了2億4千條的消息...頓時(shí)感覺(jué)一股寒流沖上腦袋瓜...
檢查了一下logstash的配置文件
3個(gè)topic,然后線程300個(gè),看上去沒(méi)毛病啊,,(因?yàn)檫@3個(gè)topic每個(gè)有100個(gè)partition)...然后就納悶了..
之前壓測(cè)過(guò)logstash,基本上kafka多少的數(shù)據(jù)進(jìn)入,就能多少數(shù)據(jù)輸出,曾今最高壓測(cè)高達(dá)80~100M/s,,所以也沒(méi)懷疑到logstash的能力,es就更不可能了,寫(xiě)入當(dāng)時(shí)也就幾萬(wàn)條,根本遠(yuǎn)遠(yuǎn)達(dá)不到es 的瓶頸
突然想起之前也發(fā)生類似的情況,被我組長(zhǎng)調(diào)整了一下,原先線程數(shù)是3,現(xiàn)在是300,topic也增加了,,然后又想是不是線程太多的原因?qū)е碌?因?yàn)閘ogstash本身是docker部署的,cpu分配了8個(gè),300個(gè)線程會(huì)不會(huì)吃不消,因?yàn)榇嬖赾pu線程切換啊.
于是將線程調(diào)到100個(gè),發(fā)現(xiàn)還是消費(fèi)很慢,,,
破天荒的,點(diǎn)開(kāi)了第二個(gè)節(jié)點(diǎn),docker ps 看到了logstash進(jìn)程,因?yàn)橐郧岸际且粋€(gè)logstash進(jìn)程去消費(fèi)的,在第二個(gè)節(jié)點(diǎn)上看到了logstash進(jìn)程讓我感到非常意外,,因?yàn)橛∠笾兄挥幸粋€(gè)logstash節(jié)點(diǎn),,然后看了一下配置文件,,,就知道了...
原來(lái)3個(gè)節(jié)點(diǎn)都是同一套logstash配置,這樣就會(huì)導(dǎo)致有600個(gè)線程的logstash沒(méi)有利用起來(lái),,,抱著僥幸的心里調(diào)整了一下,每個(gè)節(jié)點(diǎn)都是100個(gè)線程,,竟然有效果,es的吞吐量達(dá)到了10w+,,,(沒(méi)截圖)
繼續(xù)調(diào)優(yōu),因?yàn)樵赿tc的消息量少,dac的消息量偏中等(但是也滯后了600w消息),dic的消息量是最大的,于是在其中一個(gè)節(jié)點(diǎn)上
其他兩個(gè)節(jié)點(diǎn)都消費(fèi)dic,線程50個(gè)
然后kibana中es的吞吐量
基本都在30w+,40w左右~~~,
所以這里也涉及到一個(gè)kafka的消費(fèi)機(jī)制,一個(gè)topic的partition最多被一個(gè)線程消費(fèi),logstash配置的線程數(shù)也不宜過(guò)多,但是所有節(jié)點(diǎn)的總線程數(shù)必須要比topic下的partition小或者等于才行,這樣資源才會(huì)合理利用...
over!
附上查消息偏移量的命令:
0.9版本查看消費(fèi)進(jìn)度
kafka-consumer-offset-checker --zookeeper localhost:2181/kafka --group dac-logstash --topic dtc
1.1.0版本查看消費(fèi)進(jìn)度
./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group dpc_group_01
