Pod的内存使用率很高的问题分析
生产环境中在流量高峰期出现pod内存使用率很高，pod批量重启，错误日志中还有OOM相关信息。
查看堆内存的使用值
Pod使用的内存不能直接在pod中通过top命令查看，这种方式看到的是pod所在node的资源使用情况。想查看pod的资源使用情况需要用kubectl top pod xxx命令。但这也只能看到pod的内存使用。
那如何查看jvm的堆内存使用呢？
通过kubectl exec -it pod-name /bin/bash 连接到pod内部的shell，然后执行jmap，jstat等命令来查看JVM堆内存情况。
如果接入了Prometheus，则可以通过
sum(jvm_memory_used_bytes{pod="$pod", area="heap"})
sum(jvm_memory_committed_bytes{pod="$pod", area="heap"})
sum(jvm_memory_max_bytes{pod="$pod", area="heap"})
这几项指标来查看当前正在使用，已申请的和最大的堆内存大小。
通过查看指标发现堆内存很小，大约为pod内存的1/4，这是一个很小值，显然是不合理的。
pod中堆内存参数
在应用容器化之前，应用部署在物理机器上，通常会通过-Xms和-Xmx来设置堆的最小值和最大值。但出现容器化之后，通过这种静态值来设置堆内存大小就不合适了，因为pod的内存大小是可设置的，不像物理机一样是固定的。
因此，JDK8U191为了适配docker容器新增了几个参数，分别是：
MaxRAMPercentage,InitialRAMPercentage和MinRAMPercentage，同时将InitialRAMFraction,MaxRAMFraction和MinRAMFraction标记为deprecated状态。
比较违反直觉的是，MinRAMPercentage并不是最小堆内存的意思，而是当实际内存小于96m的时候，用于计算最大堆内存，也就是说，最大堆内存计算方式如下：
phys_mem * MinRAMPercentage / 100 (if this value is less than 96M)
MAX(phys_mem * MaxRAMPercentage / 100, 96M)
通常情况下实际内存不可能小于96m，忽略MinRAMPercentage即可。那实际生效的就是初始化大小比例和最大比例两个参数生效。这两个参数的默认是多少呢？
我们进入pod，运行命令
java -XX:+PrintFlagsFinal -version | grep RAMPercentage
可以看到结果如下：
double InitialRAMPercentage = 1.562500
double MaxRAMPercentage = 25.000000
double MinRAMPercentage = 50.000000
最大堆内存为实际内存的25%，这也是为什么在生产环境中使用的堆内存始终只有pod内存的1/4。
因为堆内存太小，当流量高峰出现时OOM就可以理解了。但还是无法解释pod内存使用率很高的问题(堆外内存应该占用不了多少内存)。
参数优化
分析了OOM原因之后，添加了两个参数：
-XX:InitialRAMPercentage=25
-XX:MaxRAMPercentage=70
同时也将pod内存从1.5G调大到了2G。
重新部署之后服务正常，不再出现pod重启。每个pod的堆内存使用在1个G左右，而不是原来300多M。
优化后，理论上每个pod的最大堆内存可使用至1.4G，是够用的。
但是pod内存使用率还是保持高位，从而导致根据pod设置的hpa扩缩容策略失效，只会扩容，不会缩容。
直接给出原因：JVM在流量高峰期使用了较高的内存，随后该内存一直由JVM管理，并不会归还给操作系统。
这似乎有点难以理解，在我之前的认知里面，通过垃圾回收器回收的内存应该要归还给操作系统，但其实不是这样的。实际上，JVM向操作系统申请内存是有代价的，如果每次gc后将内存归还，然后用到的时候再申请，这将极大损耗JVM的性能。
因此默认情况下，JVM是不会在短时间内主动归还未使用的内存的。当然，具体的机制取决于JDK的版本和垃圾回收器。明确的官方说明我并没有从google上搜索到，但有一点是可以确认的，OpenJDK遵循这一原则1，并且在OpenJDK12版本中引入了一个新功能：鼓励G1垃圾回收器自动将未使用的内存归还给操作系统。如下所示：
如何降低pod的内存使用率
JVM中有两个参数，分别是MinHeapFreeRatio和MaxHeapFreeRatio，含义是允许JVM保留的最小和最大的未使用内存比率，默认值分别是40和70。其中MaxHeapFreeRatio 在OpenJDK11之后的版本中被废弃。但有一些其他参数可以控制堆空间的收缩行为：
- -XX:MinHeapFreeRatio：该参数用于设置最小堆空闲空间比例的阈值。当堆空间的空闲空间低于该阈值时，JVM会尝试扩展堆空间以提供更多空闲空间，在G1中不生效。
- -XX:GCTimeRatio：该参数用于设置垃圾收集时间与应用程序执行时间的比率。较高的值将导致JVM更积极地回收内存并进行堆空间的收缩。在G1中不生效。
- -XX:AdaptiveSizePolicy：该参数启用自适应堆大小调整策略，JVM将根据应用程序的行为动态调整堆大小。这可以包括堆空间的扩展和收缩。
但即使发生堆收缩，未使用的内存是否会归还给操作系统，还是取决于具体的JVM和垃圾回收器。除非进行显式的System.gc()的调用。
最终未找到合适的将JVM内存归还给操作系统的方法，因此只能去掉了HPA中memory的策略，只保留CPU策略。
只保留CPU扩缩容策略引起了一些其他的问题，当然，这不在本文讨论的范围之内。
参考资料
[1].https://docs.openshift.com/container-platform/4.8/nodes/clusters/nodes-cluster-resource-configure.html#nodes-cluster-resource-configure-jdk-unused_nodes-cluster-resource-configure:~:text=to%20be%20calculated.-,Understanding%20how%20to%20encourage%20the%20JVM%20to%20release%20unused%20memory%20to%20the%20operating%20system,-By%20default%2C%20the
å