jvm_memory_bytes_used和jvm_gc_collection_seconds_sum

本文链接：https://blog.csdn.net/hezuijiudexiaobai/article/details/144761623

kafka_server_BrokerState_value针对 Kafka 的 JVM 配置了 32G 内存，出现高频 GC (jvm_gc_collection_seconds_sum 高) 和内存使用率接近上限（jvm_memory_bytes_used 达到 32G）的情况，可以从以下几个方面来排查问题：

1. 确认 JVM 参数配置是否合理

堆内存分配：
- 确保 -Xmx 和 -Xms 的值一致，避免频繁调整堆大小。
- 32G 内存虽然可用，但超过 32G 堆时可能导致垃圾回收效率下降（因为超过 32G 会触发 Compressed Oops 的禁用）。如果可以，建议调整为稍低于 32G，例如 31G。
垃圾回收器选择：
- 查看是否使用了合适的垃圾回收器：
  - G1GC：适合较大的堆，并能减少长时间的 GC 暂停。
  - CMS：在低延迟场景中也常见，但在高堆内存中可能表现不佳。
- 确认 JVM 启动时是否指定了 -XX:+UseG1GC 或其他垃圾回收器参数。

2. 监控和分析 GC 日志

启用 GC 日志：

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/path/to/gc.log

分析 GC 日志：
- 查看是否存在频繁的 Minor GC 或 Full GC。
- 如果 Full GC 很频繁，可能是：
  - 老年代内存不足。
  - 内存泄漏。
  - 大量对象未及时被回收。
工具推荐：
使用如 GCEasy 或其他 GC 分析工具自动分析日志。

3. 分析 Kafka 的内存使用情况

检查 Kafka Topic 配置：
- 每个 Partition 会占用一定内存，确保 num.partitions 配置合理。
- Topic 的 retention.bytes 和 retention.ms 是否设置过高，导致较多数据在内存中占用。
Producer/Consumer 的速率：
- 生产者是否发送过多的消息导致缓存积压。
- 消费者消费速度是否过慢，导致数据堆积在内存中。
缓冲区设置：
- 检查 Kafka 的内存缓冲区配置，例如 message.max.bytes 和 log.segment.bytes，确保其大小与使用场景匹配。
Page Cache：
Kafka 可能会使用堆外内存进行 Page Cache 管理，确认是否分配了足够的系统内存。

4. 内存泄漏排查

工具检测：
- 使用工具如 VisualVM、JProfiler 或 MAT (Memory Analyzer Tool) 查看堆内存中的对象分布。
- 检查是否存在异常的大对象（如 Map、List 等）占用大量内存。
Kafka 自定义代码：
- 如果你有自定义的 Kafka Producer/Consumer 逻辑，检查是否有内存泄漏。
- 避免消息缓冲区或回调队列无限增长。

5. 硬件和操作系统资源检查

操作系统内存分配：
- 确保操作系统分配给 Kafka 的内存充足。
- 检查是否存在其他应用与 Kafka 争夺内存资源。
磁盘 IO 和 Page Cache：
- 磁盘性能瓶颈可能导致 Kafka 缓存数据过久。
- 查看系统的 Page Cache 使用情况 (free -h 或 vmstat)。

6. 调整 Kafka 配置

重要参数：
- num.network.threads 和 num.io.threads：设置合适的线程数，避免线程阻塞导致内存积压。
- queued.max.requests：调整请求队列大小，避免过多的内存占用。
- log.cleaner.threads：清理日志的线程数是否足够。
数据分区优化：
- 如果消息积压严重，考虑增加分区，分散内存压力。