性能分析
测试系统配置:
- 1核心2G内存虚拟机充当redis+logstash(server)+elastersearch服务器(以下称server端)
- 1核心1G内存虚拟机充当logstash(agent)客户端(以下称agent端)
性能消耗:
1. 在agent中,使用shell脚本生产日志,输出到文件,每秒大约产生800条日志,logstash每秒收集880条日志发送给另一虚拟机的server端;当一共发送13w条数据在server的redis队列中时,这一过程中,logstash占用内存在180MB左右,单核1G的CPU使用率在82%~92%之间,日志收集结束,回归0.2%左右。
2. 在server端,redis刚启动,没有任何数据读入和读出,占用18MB内存,CPU使用率不到1%。数据量每增加1000条,大约1.2MB,内存增加3MB,目测增加的原因是日志进入redis之前被添加一些标签、字段名等,原因也可能是日志量少,但这并不会成为我的盲区或者造成系统性能瓶颈。logstash使用内存大约也为187MB,13w条被积攒在redis中的日志,在取出并拆分解析后发送给本server机器上的elasticsearch过程中,共花费190秒,平均每秒钟处理800条日志,近似于1MB/s.不知这个瓶颈在何处,或许是redis的IO速度,或者是logstash解析的速度。要测试可以通过logstash不做任何处理,直接转发给es(elasticsearch简称,下同),看速度是否有量级的提升。如果是,则说明logstash的分析过程很慢,否则,可能是redis,或者是写入es时的IO?但是logstash把数据交给es后应该不会等待es的存储。。有待研究
3. 大概可以得出这样的性能数据:这样的配置,如果能保持这13w条数据的处理速度时,每天可处理6000w条日志,即60GB。
懵逼了!才看到logstash有生成测试数据的input插件,有输出到null的output插件,用这些来测试单独模块的性能更