Kafka JVM 监控

除了主机监控之外,另一个重要的监控维度就是 JVM 监控。Kafka Broker 进程是一个普通的 Java 进程,所有关于 JVM 的监控手段在这里都是适用的。

监控 JVM 进程主要是为了让你全面地了解你的应用程序(Know Your Application)。具体到 Kafka 而言,就是全面了解 Broker 进程。比如,Broker 进程的堆大小(HeapSize)是多少、各自的新生代和老年代是多大?用的是什么 GC 回收器?这些监控指标和配置参数林林总总,通常你都不必全部重点关注,但你至少要搞清楚 Broker 端 JVM 进程的 Minor GC 和 Full GC 的发生频率和时长、活跃对象的总大小和 JVM 上应用线程的大致总数,因为这些数据都是你日后调优 Kafka Broker 的重要依据。

我举个简单的例子。假设一台主机上运行的 Broker 进程在经历了一次 Full GC 之后,堆上存活的活跃对象大小是 700MB,那么在实际场景中,你几乎可以安全地将老年代堆大小设置成该数值的 1.5 倍或 2 倍,即大约 1.4GB。不要小看 700MB 这个数字,它是我们设定 Broker 堆大小的重要依据!

很多人会有这样的疑问:我应该怎么设置 Broker 端的堆大小呢?其实,这就是最合理的评估方法。试想一下,如果你的 Broker 在 Full GC 之后存活了 700MB 的数据,而你设置了堆大小为 16GB,这样合理吗?对一个 16GB 大的堆执行一次 GC 要花多长时间啊?!

因此,我们来总结一下。要做到 JVM 进程监控,有 3 个指标需要你时刻关注:

  1. Full GC 发生频率和时长。这个指标帮助你评估 Full GC 对 Broker 进程的影响。长时间的停顿会令 Broker 端抛出各种超时异常。
  2. 活跃对象大小。这个指标是你设定堆大小的重要依据,同时它还能帮助你细粒度地调优 JVM 各个代的堆大小。
  3. 应用线程总数。这个指标帮助你了解 Broker 进程对 CPU 的使用情况。

总之,你对 Broker 进程了解得越透彻,你所做的 JVM 调优就越有效果。

谈到具体的监控,前两个都可以通过 GC 日志来查看。比如,下面的这段 GC 日志就说明了 GC 后堆上的存活对象大小。

2019-07-30T09:13:03.809+0800: 552.982: [GC cleanup 827M->645M(1024M), 0.0019078 secs]

这个 Broker JVM 进程默认使用了 G1 的 GC 算法,当 cleanup 步骤结束后,堆上活跃对象大小从 827MB 缩减成 645MB。另外,你可以根据前面的时间戳来计算每次 GC 的间隔和频率。

自 0.9.0.0 版本起,社区将默认的 GC 收集器设置为 G1,而 G1 中的 Full GC 是由单线程执行的,速度非常慢。因此,你一定要监控你的 Broker GC 日志,即以 kafkaServer-gc.log 开头的文件。注意不要出现 Full GC 的字样。一旦你发现 Broker 进程频繁 Full GC,可以开启 G1 的 -XX:+PrintAdaptiveSizePolicy 开关,让 JVM 告诉你到底是谁引发了 Full GC。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值