如果你的日志请求达到了5000条/秒，这里描述的技术点可用于调优。
检查操作系统配置
通过top查看系统瓶颈
如果发现Fluentd运行效率不佳，可先查看一下当前系统瓶颈在哪里：CPU？内存？磁盘IO？
避免额外运算
不要在Fluentd中执行过多的额外运算。这其实也是一个通用的使用建议。虽然Fluentd可以进行各种过滤、格式化等操作，但是过于复杂的配置难于理解和维护，也会降低其性能和健壮性。配置文件应保持尽可能的简单。
使用flush_thread_count参数
如果Fluentd输出的日志目的地是一个远端的服务器或者服务，可打开配置文件中的flush_thread_count参数，此参数默认值为1. 使用多个flush线程会掩盖网络延迟，增加并发输出。
该参数适用于所有的output插件。参考配置如下：
<match test>
@type output_plugin
<buffer ...>
flush_thread_count 8
...
</buffer>
...
</match>
- 对S3/TD插件使用外部gzip
Ruby使用GIL控制多线程的执行，同一时刻只能有一个线程运行，这在一定程度上降低了系统的并发性能。
S3/TD插件允许异步调用外部的gzip程序来进行数据压缩，这可释放CPU的部分算力来执行其他处理逻辑。
配置如下所示：
# S3
<match ...>
@type s3
store_as gzip_command
<buffer ...>
flush_thread_count 8
...
</buffer>
...
</match>
# Treasure Data
<match ...>
@type tdlog
use_gzip_command
<buffer ...>
flush_thread_count 8
...
</buffer>
...
</match>
减少内存使用
Ruby可配置GC参数以优化内存使用性能，可通过环境变量进行配置。为减少内存使用，可调整RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR为较小的值，默认为2.0，可将其调整为0.9或1.2等。具体可参考Ruby官方文档。
多worker模式
对于日志量级很大的场景，CPU通常会是Fluentd的性能瓶颈。此时可启用多worker模式，通过多个worker进程并行处理日志事件。
<system>
workers 8
</system>
