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生产量不是很大的情况下。