docker生产环境jvm性能优化方式

docker生产环境jvm性能优化

1、xmx与xms设置多大合适

docker获得的mem_usage的大小是从外部得到的java进程的内存大小，不仅仅是 -Xmx设置的大小，如果 -Xmx和docker分配的内存一致的话，由于java应用其他的地方还要占用不少的内存，导致还没有到达 -Xmx的时候就没有可以用的内存了，所以被docker容器给干掉了，从而出现了oom的情况。

java程序启动的时候需要哪些方面的内存呢？

• java程序的堆内存，最大就是 -Xmx设置的这个值
• Garbage collection在垃圾回收的时候使用的内存
• JIT optimization使用的内存
• java程序的Off-heap所使用的内存
• java程序的Metaspace所使用的内存
• JNI Code所占用的内存
• jvm启动的时候所占用的内存。

如何大体估算java进程使用的内存呢?

Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss]

猜测在设置jvm启动参数的时候 -Xmx的这个值一般要小于docker限制内存数，经过生产环境实验 -Xmx:docker的比例为 2/3 - 3/4，

一般生产环境都是用的sunjdk

所以建议xmx与xms设置一样大

• 避免JVM在运行过程中向OS申请内存
• 延后启动后首次GC的发生时机
• 减少启动初期的GC次数
• 避免动态调整jvm堆大小

2、xmn或者maxnewSize设置

xmn设置年轻代大小。

如果只是一些业务较简单的基础服务建议xmn设置为xmx的一半。

3、当xmx设置大于4G时

设置垃圾回收器 -XX:+UseG1GC

当堆内存很大时如果还是使用并发收集器，会造成gc收集比较长，这时可以将并行收集改成G1回收器

4、容器中最好增加-XX:ParallelGCThreads设置

该值可以设置为cpu核数

由于ParallelGCThreads的值默认是等于cpu核数，但是有的生产环境获取的是容器宿主机器的cpu核数，这就导致cpu核数太多，效率变差，gc时间会延长。

jvm docker支持启动参数

• XX:+UseContainerSupport：启用容器支持，JVM 将自动检测并使用容器特定的内存限制。
• -XX:InitialRAMPercentage=68：JVM 初始堆大小为主机可用内存的百分之68。
• -XX:MaxRAMPercentage=68：JVM 最大堆大小为主机可用内存的百分之68。
• -XX:+UseG1GC：开启 G1 垃圾回收器。
• -XX:+UnlockExperimentalVMOptions：解锁实验性 VM 选项，以便使用实验性功能。
• -XX:G1NewSizePercent=60：设置新生代大小占堆大小的比例为60%。
• -XX:ParallelGCThreads=11：设置并行 GC 线程数为11。
• -XX:ConcGCThreads=4：设置并发 GC 线程数为4。
• -XX:MaxGCPauseMillis=160：设置最大 GC 暂停时间为160毫秒。
• -XX:MetaspaceSize=120m：设置元空间初始大小为120MB。
• -XX:MaxMetaspaceSize=350m：设置元空间最大大小为350MB。
• -XX:MaxDirectMemorySize=300m：设置直接内存最大大小为300MB。
• -XX:+HeapDumpOnOutOfMemoryError：在内存溢出时生成堆转储文件。
• -Dio.netty.eventLoopThreads=6：设置 Netty EventLoop 线程数为6。
• -Dio.netty.tryReflectionSetAccessible=true：允许 Netty 反射调用私有方法。
• -Dlog4j2.formatMsgNoLookups=true：关闭 Log4j2 参数查找。
• -Dspring.profiles.active=sandbox：启用 Spring Boot 的沙盒配置文件。
• –add-exports=java.base/jdk.internal.misc=ALL-UNNAMED：导出指定的包以供未命名模块使用。
• -jar：指定 JAR 包的路径和名称。

综上所述：

这些启动参数可以优化 JVM 的内存管理、垃圾回收、线程处理等方面的性能，提高应用程序的稳定性和响应速度。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。