一次JVM参数调优记录

最近线上服务器pod中的容器总是莫名其妙重启，但是预发和测试环境都没有存在此现象。从最初怀疑是JVM配置问题开始，到定位出问题所在，花了三天左右时间，因此有必要在此做一个记录。

JVM参数配置

这台服务器是通过k8s管理的，通过kustomize来配置不同环境（测试/预发/生产）下不同的参数。

JVM_MINIMUM_MEMORY: 512M 设置Xms;

JVM_MAXIMUM_MEMORY:2048M 设置Xmx;

• -Xms512M：为jvm启动时分配的内存为512M，初始化内存。
  此值可以设置为与Xmx一致，避免每次垃圾回收后JVM重新分配内存。
• -Xmx2048M: 为jvm运行过程中分配的最大内存，最大可用内存。
  如果程序运行需要的内存超出了这个设置值，就会抛出OutOfMemory异常。
• -Xmn200M: 年轻代内存。
  JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。
  持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
• -Xss1M: 设置每个线程的堆栈大小。
  JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。

调优过程

首先是觉得服务器内存过小，于是申请将内存扩容到了4G。运行一段时间后还是出现pod里容器被自动重启的现象。

简单说一下pod的容器自动重启管理。

Pod是k8s部署集群中的进程。Pod中封装着应用的容器（如tomcat, jboss,netty），Pod是应用的一个实例。

k8s会对pod的健康状态进行监测，即k8s的容器探测（container probe）功能。它会对容器周期性执行健康状态诊断。

容器探测又分为存活性探测和就绪性探测。存活性探测用于判断容器是否处于“运行”(running)状态，如果未检测通过，则根据重启策略判断是否需要重启容器；就绪性探测则用于判断容器是否可对外提供服务，未检测通过则表明服务尚未准备就绪。

重启策略（restartPolicy）在kubctl中可配置，默认值为Always，可选值OnFailure和Never.

另外，pm2也是一个keep alive的工具，能在服务崩溃时自动重启。

其次觉得是Xms设置过小导致内存重新分配，将其设置为与Xmx值一致。问题依然存在。

我们开始从应用服务本身分析，是否有内存溢出的情况，于是开始分析pod重启前后的日志。pod重启后容器本身的日志是看不到重启之前信息的，于是通过时间段去Azure的日志管理器查询。

经过多次监听重启日志，发现日志输出信息都与数据导出为excel有关，初步认定是此功能发生内存溢出，于是直接去生产环境进行测试，点击导出1w+数据，果然，内存占用蹭蹭蹭上升，一直到180%后pod开始重启容器。至此找出了问题所在。

参考资料：

(五)Kubernetes Pod状态和生命周期管理 - 别来无恙- - 博客园

使用容器见解查看实时数据 - Azure Monitor | Microsoft Docs