Kafka 在 Ubuntu 上资源占用高的定位与优化
一、快速定位占用来源
- 先看系统层面整体负载：用 top/htop 观察 CPU、内存、I/O（iowait） 是否异常；iowait 高多为磁盘瓶颈，CPU sys 高多为系统调用或网络/磁盘中断密集。
- 针对 Kafka 进程做线程级定位：用 jstack 抓取线程栈，配合 top -H -p <kafka_pid> 找出占用高的线程，转换为 16 进制后在 jstack 中定位具体代码路径（网络、I/O、压缩、GC 等）。
- 检查文件描述符与连接数：ulimit -n 查看软限制；/proc//fd 统计已打开句柄；lsof -p | wc -l 快速评估连接/文件压力，判断是否逼近或触达上限。
- 若见到 “Too many open files” 或连接建立失败，多半是 FD 限制或连接风暴引起，需要同时做系统与服务端调优。
二、内存占用高的处理
- 合理设置堆大小：在启动脚本中设置 KAFKA_HEAP_OPTS=“-Xms2G -Xmx2G”（示例为 2GB，请结合实例内存与业务峰值调整，避免过大导致 GC 停顿过长或挤压 OS 页缓存）。
- 控制 GC 停顿：优先选用 G1 GC（或合适的低停顿收集器），并合理设置堆与新生代比例，减少 Full GC 与停顿抖动。
- 降低对象驻留：优化生产/消费批处理与缓存策略，避免一次性拉取/缓存过多消息；消费者侧在 poll 循环中控制批量与处理节奏，防止在用户态堆积大对象。
- 留出 OS 页缓存：Kafka 依赖顺序写与页缓存加速，堆不宜占满物理内存，通常建议为物理内存的**50%–70%**留给堆，其余留给页缓存与操作系统。
三、CPU 占用高的处理
- 线程与 I/O 线程配比：将 num.network.threads、num.io.threads 设为磁盘数的倍数且不超过 CPU 核数；num.replica.fetchers 一般建议不超过 5，避免副本同步线程过多引发 CPU 竞争。
- 分区与负载均衡：分区数建议为节点数的倍数，单个节点分区数尽量不超过 2000；避免热点集中与不均衡的消费者分配策略（必要时调整分区或消费者并发度）。
- 客户端与协议栈因素：排查 C++/Logstash 等客户端版本兼容问题（频繁全量元数据请求、鉴权 Deny 风暴会显著抬升 CPU）；同时关注 sssd 异常导致的鉴权循环。
- 借助 jstack 精确定位：对高 CPU 线程做 16 进制映射，确认是否为网络处理、压缩、复制、元数据或鉴权路径，再定向优化客户端/配置/版本。
四、磁盘与网络瓶颈的优化
- 存储硬件：优先使用 SSD/NVMe，并确保磁盘空间充足；合理规划 log.dirs 多盘并行写入，减少单盘热点。
- 利用顺序写与零拷贝：Kafka 顺序追加写、sendfile 零拷贝与页缓存能显著降低 CPU 与 I/O 开销，尽量避免频繁小文件与随机写。
- 网络栈与参数：适当增大 socket.send.buffer.bytes / socket.receive.buffer.bytes，提升大流量下的网络吞吐；结合业务调优 socket.request.max.bytes，避免异常大请求拖垮网络栈。
- 分区与压缩：适度合并小 Topic、减少过度分区以降低随机 I/O；开启消息压缩（如 snappy、lz4、zstd）减少网络与磁盘占用。
五、系统与 Kafka 配置落地清单
- 提升文件描述符与连接上限：
- 在 /etc/security/limits.conf 或 /etc/security/limits.d/90-kafka.conf 增加：kafka soft/hard nofile 65536；
- 若用 systemd 启动：systemctl edit kafka，加入 [Service] LimitNOFILE=65536，随后 daemon-reload 并重启服务。
- 典型 Kafka 与 OS 关键参数示例（按实际调优）：
- OS：ulimit -n 65536；必要时调高 net.core.somaxconn、net.ipv4.tcp_max_syn_backlog；
- Broker：num.network.threads（≈磁盘倍数且 ≤CPU 核数）、num.io.threads（同前）、num.replica.fetchers ≤ 5；
- Producer：batch.size、linger.ms、compression.type（snappy/lz4/zstd）；
- Consumer：fetch.min.bytes、fetch.max.wait.ms；
- JVM：KAFKA_HEAP_OPTS=“-Xms2G -Xmx2G”，配合合适的 GC 策略。
- 版本与架构：Kafka 2.8+ 可考虑 KRaft 模式替代外部 ZooKeeper，减少组件与网络开销；同时确保客户端与服务端版本匹配。
