背景
在日常运维 ZooKeeper 中,经常会遇到长时间无法选主,恢复时进程启动又退出,进而导致内存暴涨,CPU 飙升,GC 频繁,影响业务可用性,这些问题有可能和 jute.maxbuffer 的设置有关。本篇文章就深入 ZooKeeper 源码,一起探究一下 ZooKeeper 的 jute.maxbuffer 参数的最佳实践。
1.png
2.png
分析
首先我们通过 ZooKeeper 的官网上看到 jute.maxbuffer 的描述:
jute.maxbuffer :
(Java system property: jute.maxbuffer).
......, It specifies the maximum size of the data that can be stored in a znode. The unit is: byte. The default is 0xfffff(1048575) bytes, or just under 1M.
When jute.maxbuffer in the client side is greater than the server side, the client wants to write the data exceeds jute.maxbuffer in the server side, the server side will get java.io.IOException: Len error
When jute.maxbuffer in the client side is less than the server side, the client wants to read the data exceeds jute.maxbuffer in the client side, the client side will get java.io.IOException: Unreasonable length or Packet len is out of range!
从官网的描述中我们可以知道,jute.maxbuffer 能够限制 Znode 大小,需要在 Server 端和 Client 端合理设置,否则有可能引起异常。
ZooKeeper调优:jute.maxbuffer避坑实践

本文深入探讨了ZooKeeper中jute.maxbuffer参数对服务稳定性的影响,分析了由于该参数设置不当导致的长时间无法选主、服务启动退出等问题。通过源码解析,揭示了jute.maxbuffer不仅限于Znode大小,还影响所有使用readString和readBuffer的Record。建议在客户端和服务端保持jute.maxbuffer设置一致,避免异常,并监控last_proposal_size指标以预防过大提案。同时,给出了在MSE ZooKeeper中调整参数和设置告警的实践建议。
最低0.47元/天 解锁文章
992

被折叠的 条评论
为什么被折叠?



