CentOS 上 Kafka 卡顿的定位与优化步骤
一、快速定位瓶颈
- 系统资源：用 top/vmstat 看 CPU、load、si/so（swap 活动）；用 iostat -x 1 观察 await、svctm、util，util 持续接近 100% 多为磁盘瓶颈；用 sar -n DEV 1 看 rxkB/s/txkB/s 与丢包重传。
- 磁盘与文件系统：确认日志目录在 SSD、挂载选项含 noatime，文件系统优先 XFS。
- 网络：检查带宽是否打满、是否有丢包/重传，跨机房/跨可用区时尤为关键。
- Kafka 内部：
- 查看是否有 UnderReplicatedPartitions、RequestQueueSize 是否持续升高；
- 消费者组用 kafka-consumer-groups.sh 查看 LAG 是否持续增长；
- 主题层面用 kafka-topics.sh 查看 Leader/ISR 是否稳定。
这些指标能快速判断是 磁盘 I/O、网络、CPU 还是副本/重平衡导致的卡顿。
二、操作系统与存储优化
- 减少换页与脏页抖动：将 vm.swappiness=1；适度设置 vm.dirty_background_ratio≈5、vm.dirty_ratio≈60–80，避免设置 0 导致内核持续刷脏页引发长停顿。
- 文件与挂载：日志目录使用 SSD；挂载加 noatime；优先 XFS 文件系统。
- 资源限制：提升进程可打开文件数（如 ulimit -n）、调大 vm.max_map_count，避免 “Too many open files / max map count” 限制。
- 网络栈：适当增大 socket send/recv buffer，提升高吞吐下的网络吞吐。
这些系统层面的优化对 Kafka 的 页缓存利用、磁盘写放与网络吞吐有直接收益。
三、Broker 关键配置建议
- 并发与线程：
- num.network.threads（网络处理）≈ CPU 核数；
- num.io.threads（磁盘 I/O）≥ 磁盘数，常见为 CPU 核数的 2 倍以内；
- background.threads=10+、num.recovery.threads.per.data.dir=10+（大数据量启动/恢复更快）；
- queued.max.requests 适度增大以缓冲峰值请求（避免 OOM）。
- 副本与可用性：
- min.insync.replicas=2（在 acks=all 时保证持久性）；
- replica.lag.time.max.ms=60000（网络抖动容忍度）；
- unclean.leader.election.enable=false（避免数据丢失）。
- 网络与 I/O：
- socket.send.buffer.bytes / socket.receive.buffer.bytes=102400（可按带宽适当上调）；
- replica.socket.receive.buffer.bytes=65536；
- 适度提升 num.replica.fetchers 增加副本同步并发。
- 日志与段：
- log.segment.bytes=1073741824（1GB），减少小文件数量、加快启动与清理；
- 仅在必要时调整 log.flush.interval.messages/ms，避免频繁强制刷盘影响吞吐。
- 默认分区与副本：
- num.partitions=8、default.replication.factor=3（可按业务并发与容灾要求调整）。
以上参数能显著改善 请求排队、副本同步、磁盘 I/O 并发与启动恢复等环节的卡顿。
四、生产者与消费者调优
- 生产者：
- 启用批量与压缩：batch.size（如 16KB–64KB）、linger.ms（如 5–20ms）、compression.type=snappy/lz4/zstd；
- 可靠性：acks=all 配合 min.insync.replicas=2；
- 高吞吐场景可适当提高 max.in.flight.requests.per.connection（在 acks=all 下权衡顺序性与吞吐）。
- 消费者：
- 控制每次处理量：max.poll.records=500（处理慢则下调），max.poll.interval.ms=300000；
- 提升拉取效率：fetch.min.bytes（按业务延迟目标调大以攒批）、fetch.max.bytes、max.partition.fetch.bytes；
- 稳定性：避免长事务/阻塞处理；必要时增加消费者实例或提高分区数以匹配并发。
这些设置可在保证可靠性的前提下，显著提升 端到端吞吐与处理延迟稳定性。
五、JVM 与监控落地
- JVM：
- 堆大小：如 -Xms4G -Xmx4G（不超过物理内存的 50%，其余留给 OS 页缓存）；
- 垃圾回收器：优先 G1GC，如 -XX:+UseG1GC -XX:MaxGCPauseMillis=20；
- 避免 Full GC 与长停顿，必要时结合容器/系统内存限制调优。
- 监控与日常巡检：
- 关键指标：UnderReplicatedPartitions、RequestQueueSize、NetworkProcessorAvgIdlePercent、broker_messages_in_rate、group_msgs（堆积）、broker_disk_usage/cpu/memory/连接数；
- 常用命令：
- 消费组延迟：kafka-consumer-groups.sh --describe --group ；
- 主题与 ISR：kafka-topics.sh --describe --topic ；
- JMX：使用 JmxTool 或 Prometheus JMX Exporter 持续采集。
- 变更与扩容：
- 调整分区/副本后采用 滚动重启；
- 消费者组开启 group.instance.id 并使用 静态成员资格，减少重平衡；
- 扩容后按流量重新均衡分区，避免 数据/流量倾斜。
通过 JVM 稳定 + 指标驱动 + 有序变更，可长期保持集群的低延迟与高可用。