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