Kafka 在 Ubuntu 的常见性能瓶颈与定位路径
一、常见瓶颈概览
- 磁盘 I/O 与文件系统：顺序写是 Kafka 的强项，但磁盘带宽、IOPS、文件系统（如 ext4/xfs）、日志段大小与保留策略配置不当，都会直接限制吞吐与延迟。单盘或 HDD 场景尤易出现瓶颈。优化手段包括使用SSD/NVMe、多盘并行（配置多个 log.dirs）、合理设置 log.retention.hours / log.retention.bytes / log.segment.bytes。
- 网络栈与连接数：高并发下，若 文件描述符上限（nofile）、TCP 队列（net.core.somaxconn、net.ipv4.tcp_max_syn_backlog）、socket 缓冲不足，会出现连接超时、请求排队、延迟抖动。Kafka Broker 与客户端都需要足够的 fd 与合理的网络线程、socket 缓冲配置。
- JVM 与 GC：堆过大或过小、GC 停顿过长都会放大尾延迟。常见做法是设置 -Xmx/-Xms 相等、选择 G1GC 并控制停顿目标，避免频繁 Full GC 与晋升失败导致的长停顿。
- 分区与副本策略：分区数不足会限制并行度；副本过多（尤其 acks=all 且 min.insync.replicas 偏高）会放大写入延迟与网络/磁盘压力。需结合吞吐目标、消费者并发与容错要求设计分区与 ISR 策略。
- 生产者/消费者端配置：生产者若 batch.size、linger.ms、compression.type 配置不当，难以形成有效批处理；消费者 fetch.min.bytes / fetch.max.wait.ms 不合理会造成空轮询或单次拉取过大导致处理阻塞。
二、快速定位步骤
- 资源与系统指标：用 htop / iotop 观察 CPU、磁盘 I/O、负载；若磁盘写带宽接近设备上限或 iowait 高，优先考虑磁盘/文件系统与分区并行度。
- 网络健康：用 ping / iperf 检查延迟与带宽；高延迟或丢包会直接转化为请求排队与重试。检查 netstat -s 的 TCP 重传与超时计数。
- Broker 内部指标：关注请求耗时分布（如 RequestHandlerAvgIdlePercent、Produce/Fetch 延迟）、网络线程与 I/O 线程是否吃满、请求队列是否堆积。
- 文件描述符与连接：在服务端执行 ulimit -n 与 lsof -p | wc -l 检查 fd 使用；若接近上限或出现 “Too many open files”，需提升 nofile 并优化连接复用与超时。
- 客户端侧排查：核对 acks、retries、batch.size、linger.ms、compression.type 与消费者的 fetch.min.bytes / fetch.max.wait.ms、max.poll.records，确认不是端侧批处理或拉取策略导致的吞吐不足。
三、关键配置与优化要点
- 磁盘与文件系统：优先 SSD/NVMe；在 server.properties 中配置多个 log.dirs 对应不同磁盘；合理设置 log.retention.hours / log.retention.bytes / log.segment.bytes 避免频繁段滚动与删除抖动。
- 网络与连接：提升 nofile ≥ 65536（/etc/security/limits.conf 与 systemd 的 LimitNOFILE）；增大 net.core.somaxconn、net.ipv4.tcp_max_syn_backlog；适度增大 socket.send.buffer.bytes / socket.receive.buffer.bytes；Broker 侧按 CPU 核数调整 num.network.threads / num.io.threads，并合理设置 socket.request.max.bytes。
- JVM：设置 -Xmx/-Xms 相等（如 8G/16G），选用 G1GC 并设置合理的停顿目标（如 -XX:MaxGCPauseMillis），避免堆过大导致 GC 停顿与晋升压力。
- 生产者：开启压缩（如 snappy/lz4/zstd），适度增大 batch.size / linger.ms 提升批处理命中率；根据可靠性目标设置 acks 与重试策略。
- 主题与副本：分区数应匹配目标吞吐与消费者并发；在强一致场景合理设置 replication.factor 与 min.insync.replicas，在吞吐与可用性间权衡。
四、Ubuntu 与服务管理注意事项
- systemd 与 fd 限制：若通过 systemd 启动 Kafka，需在服务单元中显式设置 LimitNOFILE=65536（或更高），否则仅修改 limits.conf 可能不生效；修改后执行 systemctl daemon-reload && systemctl restart kafka。
- 监控与告警：部署 JMX Exporter + Prometheus + Grafana 监控 Broker 请求耗时、I/O、网络、连接与 GC；对 磁盘空间、请求错误率、请求排队 建立阈值告警，提前识别容量与稳定性风险。
