Ubuntu 上 Zookeeper 内存配置优化指南
一 内存目标与堆大小设定
- Zookeeper 是内存密集型服务，堆太小会频繁 GC、影响延迟，太大则 GC 停顿长且浪费内存。生产上常见做法是把堆设为物理内存的 1/4 左右，并尽量保证Xms 与 Xmx 等值，避免运行期扩缩堆带来的抖动。示例：在 16GB 内存的机器上，可先尝试 -Xms4G -Xmx4G；在 32GB 内存的机器上，可先尝试 -Xms8G -Xmx8G，再结合监控微调。对于数据量较小或连接数不多的场景，2GB 堆也常见。调整方式是在 conf/java.env 中设置环境变量：
- 示例（4GB 堆）：
- export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
- export JVMFLAGS=“-Xms4g -Xmx4g $JVMFLAGS”
- 修改后用 jmap 验证：jmap -heap <zk_pid>；重启后再次核对。上述做法与常见生产建议一致，且验证方式明确可行。
二 GC 选择与关键 JVM 参数
- 推荐使用G1 GC（低停顿、可预测停顿），并开启 GC 日志与 OOM 自动 dump，便于问题定位与容量规划：
- 示例（放在 java.env 的 JVMFLAGS 中）：
- -XX:+UseG1GC
- -XX:MaxGCPauseMillis=200
- -Xlog:gc*,gc+heap=debug:file=/var/log/zookeeper/gc.log:time,tags
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/zookeeper/heapdump.hprof
- 避免把堆开得过大（例如超过10–12GB）以免 Full GC 停顿过长；同时保留足够内存给操作系统 page cache与JVM 元空间 Metaspace，减少磁盘 I/O 放大与元数据压力。
三 与内存相关的 Zookeeper 配置
- 事务日志与快照分离到不同磁盘：将 dataLogDir 指向性能更好的磁盘（优先 SSD），可显著降低写放大与 I/O 争用，直接改善内存中数据刷盘与快照触发的稳定性。
- 控制快照与日志行为：
- 启用自动清理：autopurge.purgeInterval=1（小时），autopurge.snapRetainCount=10（保留最近 N 个快照与对应日志），避免磁盘被历史文件撑爆。
- 调整快照触发阈值：snapCount 默认 100000，增大（如 3000000）可降低快照频率，减少磁盘与内存瞬时抖动；若快照很频繁，可适当减小 preAllocSize（默认 64MB，单位 KB），避免事务日志预分配过大带来的浪费。
- 限制待处理请求与连接数，防止内存被突发请求占满：
- globalOutstandingLimit：限制服务器上未响应请求总数（默认 1000），超过将拒绝新请求，保护内存与稳定性。
- maxClientCnxns：限制单客户端 IP 到单台服务器的并发连接数（默认 60），可按业务适当调大（如 2000），但不宜设为 0（无限制）。
四 监控验证与常见陷阱
- 快速健康检查与服务可达性：
- echo ruok | nc 2181；echo stat | nc 2181，确认服务状态与连接信息正常。
- 堆与 GC 监控：
- jmap -heap <zk_pid> 核对堆大小与代际分布；结合 GC 日志分析停顿与回收效率，必要时微调 -Xms/-Xmx 与 G1 参数。
- 一致性/持久化权衡（与内存/延迟相关）：
- forceSync=yes（默认）更安全但写延迟更高；forceSync=no 可降低延迟，但断电可能丢失 page cache 数据。若开启 no-sync，务必配合更严格的监控与告警。
- 避免把堆设得远超物理内存，且确保 dataLogDir 所在磁盘性能良好（SSD 优先），否则即使堆很大也会因 I/O 瓶颈导致响应变慢与 Full GC 增多。