logstash performance testing

 

最近一直在和peformance team的同事作logstash 5.6.2的測試，主要測試兩個方面：一方面測試log數據是否能所有被logstash獲取與發出去，一方面測試logstash自身的cpu和memory的使用狀況。

經過腳本生成log：總共生成10個文件，每一個文件1百萬行文本， 每行字符在100之內，長短不一。採用python多線程生成，總共耗時24分鐘左右。

測試server有2個物理CPU,每一個物理CPU有6個core, 16g內存。

logstash的output爲kafka。

經過logstash的metrics plugin記錄通過filter的event數量。

經過在output中配置file {path=>"/tmp/output.log"}，把發出去的內容print到一個local文件，用於統計最終發出去了多少條記錄。

經過jconsole進行CPU/Memony的統計

總共進行了4輪測試，每輪都能把1千萬行log記錄徹底發送出去，第一方面的測試順利經過。 

主要說說觀察到的cpu和memory的使用狀況。

 

第一輪測試（採用logstash默認參數）：

Xms1g

Xmx1g

pipeline.workers:12 

pipeline.batch.size=125

pipeline.batch.delay=5

結果：

memory usage:

 

cpu: idle:0.2%， running:3.2%~5.2%. 總共花費了40分鐘把log所有傳輸出去.

 

JVM使用狀況：

JVM KPI：

結論：堆內存的使用一直在增長，但增長的速率並不快，整個過程直到完成都沒有觸發full GC. cpu在running狀態下比較穩定，jvm的throughput > 95%屬於比較好的情況。

 

第二輪測試:增大pipeline.batch.size

Xms1g

Xmx1g

pipeline.workers:12 #default equal total core number 2*6 = 12

pipeline.batch.size=500 # 125=>500

pipeline.batch.delay=5

結果：

memory在200mb~800mb直接不斷震動，出現屢次full GC。

cpu idle:0.6% running:3%~7%。比之第一輪測試，cpu不是很stable,總共花費了43min中才傳輸完全部log。

JVM使用狀況：

JVM KPI：

 

 結論：由於增大了pipeline.batch.size致使堆內存的增加邊開，很快達到了CMS Old Gen GC的上限，全部頻繁出現GC。同時致使cpu也沒有第一輪測試時穩定。JVM througput < 95%，也沒有達到業界的優良標準。最終致使傳輸全部log所耗時間也增長了，說明並非batch size越大越好。

 

第三輪測試：下降pipeline.works

Xms1g

Xmx1g

pipeline.workers:6 # 12 => 6

pipeline.batch.size=500

pipeline.batch.delay=5

 

memory使用很是低，上升的也很慢。

cpu基本與空閒狀態類似，經過metric.log中的數據觀察到，平均每5秒大約發送500events,和batch.size設置的大小一致。這個狀態要發送完1千萬條數據，耗時很是長，因此中間停掉了測試。

JVM使用狀況：

JVM KPI:

結論：cpu分配的少，致使內存使用也保持在一個相對較低的水平，jvm kpi雖好，是由於沒有重複使用resource。最終致使logstash的工做效率也很低，沒能發揮它的所有能力。

 

第四輪測試：減低分配的JVM內存。

Xms512mb (1g => 512mb)

Xmx512mb (1g => 512mb)

pipeline.workers:12 

pipeline.batch.size=125

pipeline.batch.delay=5

 

Memory使用狀況：剛開始須要處理10個文件新建立出來的文件的時候，內存使用比較多。發生了一次CMS Old Gen GC後，後續heap使用平穩上升.

cpu相對比較穩妥，running：3.2% ~ 5.2%。耗時41分鐘，發送完全部log。

結論：memory的分配減小了50%,並無發現logstash的工做效率有明顯下降，若是產線內存吃緊，能夠大膽選擇減小給logstash的內存分配，固然前提是log生產量不是很大的情況下。