最近一直在和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生产量不是很大的状况下。