这是一个创建于 2282 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天部署了个 3 broker 的 kafka 集群。 做了下基准的压力测试，刚开始的时候没有使用任何压缩策略。
发现吞吐量真是渣的不行，最多就 4~5w message/s。 看到网上有人压测都是上百万的，感觉是哪里不对劲（当然机器配置也不好，虚拟机 6 核 2394 MHZ，16G 内存）
下面的测试都是 3 个分区，3 个副本的 topic
未启用压缩
1000000 records sent, 28302.954828 records/sec (55.28 MB/sec),
487.26 ms avg latency, 1628.00 ms max latency,
11 ms 50th, 1500 ms 95th, 1551 ms 99th, 1603 ms 99.9th.
使用 lz4 压缩算法
1000000 records sent, 113237.458951 records/sec (221.17 MB/sec),
301.43 ms avg latency, 1224.00 ms max latency,
221 ms 50th, 995 ms 95th, 1128 ms 99th, 1173 ms 99.9th.
使用官方的基准测试工具测试的：
./kafka-producer-perf-test.sh --num-records 1000000 \
--producer.config ../config/producer.properties \
--topic test-3p-3r-lz4 --record-size 2048 --throughput 150000
现在对 kafka 的原理还没有深入了解。实践后，发现压缩对吞吐量提升出乎意料啊！使用压缩算法后：
- 整体吞吐量提高了
- 延迟降低的并不多
第二点现在不知道瓶颈在哪里，也许是内存。现在内存的配置是参考 LinkedIn 给出的实践配置：
KAFKA_HEAP_OPTS="-Xmx12g -Xms12g -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80"
监控 GC 日志，也没有发现 GC 有特别耗时的情况。
 |
1
kkfnui OP 刚重新看了下日志，启用压缩有吞吐量已经达到 250MB/s 左右了。
延迟的问题是由于网络带宽导致的。 |
Select Language