生产环境中的flume海量数据传输性能优化
上一篇文章，记flume部署过程中遇到的问题以及解决方法，记录了flume在运行过程中遇到的问题的解决方法，本文将记录在项目调试过程中对flume性能的优化。
再放上项目的拓扑结构图：
实际生产环境中，agent层的机器大约有50台，在高峰时期生成的日志量大约在5000条/s, 每天总共生成的日志量大约在8T左右, collector的机器有8台，所以对该系统的传输效率有很高的要求。
在测试中，发现在使用基本配置时，flume发送数据的效率并不是很理想，agent向collector发送数据最快也就每秒1000条左右，远不能满足系统传输需求，在随后的调试过程中，通过修改jvm环境参数以及agent、collector层的配置，逐步使得传输性能达到要求，现将调试过程记录如下：
agent层的调试数据：
| 优化方法 | java 环境 | channel类型 | sink类型与个数 | 是否压缩 | source接收到条数&速度 | channel已写入 &channel占用率 | sink输出量 | sink输出速度 | cpu占用 | 内存占用 | 总结 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 无 | 默认 | file 100w | 负载均衡 2个avro sink | 否 | 2472192 1373/s | 2473728 0.02% | 2360100 | 1311/s | 约35% | 8.6G | 传输效率很低 |
| 优化java配置,启用2G内存 | Xms2g Xmx2g Xss256k Xmn1g | file 100w | 负载均衡 2个avro sink | 否 | 6226688 3459/s | 6227712 99.90% | 5228000 | 2904/s | 约30% | 8.6G | 传输效率有较大提升 |
| avro压缩传输 | Xms2g Xmx2g Xss256k Xmn1g | file 100w | 负载均衡 2个avro sink | 是 | 5076224 2820/s | 5077504 99.90% | 4077800 | 2265/s | 约47% | 10.4G | 传输效率不升反降 |
| 采用memory channel | Xms2g Xmx2g Xss256k Xmn1g | memory 100w | 负载均衡 2个avro sink | 是 | 6767104 3759/s | 6771968 99.90% | 5772200 | 3207/s | 100%-200% | 10.4G | 传输效率有少量提升，但是cpu压力很大 |
| 数据不传输到L2，直接sink到本地 | Xms2g Xmx2g Xss256k Xmn1g | file 100w | 负载均衡 2个file sink | 否 | 5761280 3201/s | 5762816 0.00% | 5761662 | 3201/s | 10%-50% | 10.4G | channel无堆积，但是传输量无明显提升 |
| 将数据传给8个Sink组成的L2 | Xms2g Xmx2g Xss256k Xmn1g | file 100w | 负载均衡 8个avro sink | 否 | 1423616 791/s | 1393664 99.90% | 393700 | 218/s | 5% | 10.4G | 传输效率极低 |
| 优化avro-avro传输，avro sink配置maxIoWorkers128，L2的avro source threads设为1000 | Xms2g Xmx2g Xss256k Xmn1g | file 100w | 负载均衡 2个file sink | 否 | 2971392 1651/s | 2972416 99.90% | 1972500 | 1095/s | 5%-20% | 10.4G | 传输效率不升反降 |
| 将L2数据sink到本地 | Xms2g Xmx2g Xss256k Xmn1g | file 100w | 负载均衡 2个avro sink | 否 | 6279168 3488/s | 6280448 99.90% | 5280500 | 2934/s | 约30% | 10.4G | 传输效率无明显提升 |
| 增大java内存 增大avro sink batchsize 启用压缩 启用memorychannel | Xms8g Xmx8g Xss256k Xmn3g | memory 100w | 负载均衡 2个avro sink | 是 | 5640704 3134/s | 5643776 99.90% | 4644000 | 2580/s | 30% | 16.5G | 传输效率无明显提升 |
| 增加jvm内存到8G，filechannel设为1000w容量 | Xms8g Xmx8g Xss256k Xmn3g | file 1000w | 负载均衡 2个file sink | 否 | 7330816 4073/s | 7332096 48% | 2519000 | 1399/s | 2%-16% | 16.5G | 传输效率不升反降 |
| 在上一种方法的基础上增加avro batchsize为2000 | Xms8g Xmx8g Xss256k Xmn3g | file 2000w | 负载均衡 2个avro sink | 否 | 8168960 4538/s | 8170496 69% | 1270000 | 706/s | 10%-20% | 16.5G | 传输效率极低 |
| 4个sink无组策略 | Xms8g Xmx8g Xss256k Xmn3g | file 2000w | 无组策略 4个avro sink | 否 | 7222272 4012/s | 7223808 0.02% | 7222272 | 4012/s | 30%-50% | 16.6G | 取消负载均衡，效率有较大提升666 |
| 8个sink无组策略 | Xms8g Xmx8g Xss256k Xmn3g | file 2000w | 无组策略 8个avro sink | 否 | 7034624 3908/s | 7035648 0.03614% | 7032034 | 3906/s | 30%-50% | 16.6G | 无组策略的情况下，8个sink和4个sink效率无差 |
| 4个sink无组策略 memrorychannel | Xms8g Xmx8g Xss256k Xmn3g | memory 100w | 无组策略 4个avro sink | 否 | 17435648 9686/s | 17441536 47.56% | 12678000 | 7043/s | 100%-500% | 16.6G | cpu压力很大 |
| 2个sink无组策略 memrorychannel L2的内存channel扩大到1亿 | Xms8g Xmx8g Xss256k Xmn3g | memory 100w | 无组策略 4个avro sink | 否 | 18679438 10337/s | 18684778 0.00256% | 18683444 | 10448/s | 10%-20% | 16.6G | 此为目前传输最快的方案 |
| 8个sink无组策略，2G内存 | Xms2g Xmx2g Xss256k Xmn1g | file 2000w | 无组策略 8个avro sink | 否 | 7067392 3926/s | 7068416 0.00256% | 7067212 | 3926/s | 30%-40% | 10.8G | jvm2G内存已经够用 |
| 8个sink无组策略，2G内存,压缩 | Xms2g Xmx2g Xss256k Xmn1g | file 2000w | 无组策略 8个avro sink | 是 | 7362048 4090/s | 7363072 0.0055% | 7361995 | 4090/s | 50%-100% | 10.6G | L1到L2压缩对传输速度无太大提升，增大了CPU负担 |
| 4个sink无组策略，2G内存,压缩 | Xms2g Xmx2g Xss256k Xmn1g | file 2000w | 无组策略 4个avro sink | 是 | 7501056 4167/s | 7502592 0.01664 | 8036352 | 4464/s | 40%-50% | 10.5G | 从channel获取的数量大于channel写入的数量，说明此时的瓶颈在channel写入 |
| 4个sink无组策略，2G内存,不压缩 | Xms2g Xmx2g Xss256k Xmn1g | file 2000w | 无组策略 4个avro sink | 否 | 7745792 4303/s | 7747328 0.02688 | 7741952 | 4301/s | 50%-100% | 10.5G | L1到L2压缩对传输速度无太大提升，增大了CPU负担 |
| 8个sink无组策略，发送到4个L2，每个L2有两个source，两个channel | Xms2g Xmx2g Xss256k Xmn1g | file 2000w | 无组策略 8个avro sink | 否 | 6734336 3741/s | 6735360 0.00177 | 6735006 | 3742/s | 30%-50% | 10.8G | 发给同一机器的两个avro source无性能提升 |
collector层的调试数据：
| 优化方法 | java 环境 | channel类型 | sink类型与个数 | 是否压缩 | source接收到条数&速度 | channel已写入 &channel占用率 | sink输出量 | sink输出速度 | cpu占用 | 内存占用 | 总结 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 正常传输 | Xms20g Xmx20g Xss256k Xmn8g | file 100w | 无组策略 1个kafka sink | 否 | 3099048 1722/s | 3095238 99.90% | 2144761 | 1192/s | 2%-5% | 25.6G | 输出速度不够 |
| 增加到4个sink，filechannel容量扩大 | Xms20g Xmx20g Xss256k Xmn8g | file 1亿 | 无组策略 4个kafka sink | 否 | 18850000 10472/s | 18850000 9.86% | 8970971 | 4984/s | 50%-100% | 25.6G | 速度提升约4倍 |
| 使用memory channel | Xms20g Xmx20g Xss256k Xmn8g | memory 1000w | 无组策略 4个kafka sink | 否 | 17794000 9886/s | 17744000 99.95% | 7745000 | 4303/s | 100%-800% | 25.6G | 相比使用file channel无性能提升 |
| 增加到8个sink | Xms20g Xmx20g Xss256k Xmn8g | file 1亿 | 无组策略 8个kafka sink | 否 | 19251655 10695/s | 19249668 2% | 17148675 | 9527/s | 100%-150% | 26.8G | 8个sink传输比1个速度提升约8倍 |
agent到collector启用zlib压缩前后的网络带宽情况
由图可见，在启用压缩前，带宽基本占用在50M左右，启用后，带宽占用在10M左右
总结：
1、默认jvm环境只使用了20m内存，需要调整，扩大到2G基本够用，不需要过大；
2、collector到kafka，启用的sink越多，传输越快；
3、如果collector到kafka通路受阻，使数据堆积在channel中，如果channel堆满，则会影响agent到collector的传输；
4、agent到collector如果配置了组策略（sink group），则一个组策略只启动一个传输线程，多个sink成一组则传输效率远不如sink各传各的，一个sink相当于一个传输线程；
5、通路不受阻的情况下，memoryChannel传输效率比fileChannel高很多，不过对cpu、内存的要求会很高；
6、avro压缩传输对传输效率没有太大提升，反而增大cpu负担,但是会大大降低网络带宽；
7、在网络带宽受限的情况下，增加sink、改用memory channel等方法都不能增加传输效率；
8、影响flume传输性能的主要因素有，jvm内存、网络带宽、channel类型、sink个数、是否压缩、机器硬件性能，各条件需要做一个综合的性能平衡，某一个环节出现瓶颈就会影响整个系统的传输性能。
ps：****的表格使用起来太蛋疼了…这个表格搞了我整整一个下午加一个晚上…