产线服务JVM和容器yaml内存、CPU配置最佳实践

最佳实践：

一、JVM调参

1、容器resource的limit.memory：根据服务运行情况给出设置（一周的运行趋势得出）

2、服务的JVM -Xmx (最大堆大小)：Pod的limits.memory的70%-80%

3、服务的JVM -Xms (初始堆大小)：设置同 -Xmx（避免差异过大引起GC回收紊乱）

4、容器resource的request.memory：-Xms (初始堆大小)上浮一定余量（建议JVM -Xms 上浮0.5-1G ）

二、遇到服务异常（OOM 优化参数配置）

1、ACK里面 Prometheus 看应用的节点监控： 比对WSS 和 RSS ，WSS工作区和RSS物理区相当接近时候，并且使用很高，说明 接近limit 需要调整limti大小

2、ARMS里面，应用详情监控：看JVM监控，使用总和接近最大允许使用内存的时候，JVM里面的最大堆和初始堆需要按照业务的数据集体量调整

3、如果 OOM关键词在SLS没有看到，说明是堆外内存溢出

一、JVM 的参数和容器负载关系

1、理解Pod资源限制：

• requests：定义了Pod运行所需的最小资源量，确保Pod能够启动并获得必要的资源保障
• limits：设定了Pod资源使用的上限，防止单个Pod过度消耗资源影响其他Pod。

2、JVM堆内存配置原则：

• -Xms (初始堆大小)：建议设置与-Xmx相同，以避免JVM在运行过程中因调整堆大小而产生的额外开销。这样可以保持内存分配的一致性，减少GC频率和提升性能。
• -Xmx (最大堆大小)：应根据Pod的limits.memory设置来调整，通常建议将-Xmx设置为Pod内存限制的70%到80%[1]，以预留部分内存给非堆内存使用（如JVM元数据、线程栈等）和系统操作。

结合实践：

-Xms2867m -Xmx2867m

• 配置示例：假设一个Pod的内存限制limits.memory为4GB(4096MB)，则可以将-Xms和-Xmx都设置为约2867MB（即4096MB的70%），确保JVM堆内存的使用与Pod资源限制相协调。

3、注意事项：

• 确保JVM堆大小的设置不超过Pod的内存限制，避免因内存溢出导致的容器被Kubernetes终止。
• 监控应用的实际内存使用情况，适时调整-Xms和-Xmx以优化资源利用和性能。
• 配置GC日志和Heap Dump路径时，考虑挂载外部存储（如NAS）以持久化存储这些重要信息，便于问题诊断。

二、Pod的resources请求(request)

1、基础内存需求

     首先确定应用在启动和运行初期的最低内存需求。这包括JVM的基本开销、类加载、线程栈空间等。虽然直接从知识库中没有具体的数字建议，但通常需要通过监控或应用特性分析来确定这一数值。

2、JVM初始堆大小(-Xms)

    由于推荐将-Xms（JVM初始堆大小）与-Xmx（最大堆大小）设置为相同值以避免运行时的内存调整开销，可以将request.memory设置为接近或等于-Xms的值。例如，如果按照推荐设置了-Xms2048m，则request.memory至少应为2048Mi（Kubernetes中内存单位为Mi或Gi，其中1Mi=1024Ki, 1Gi=1024Mi）。

3、预留系统资源

   确保除了JVM堆内存之外，还留有足够的内存给系统本身、非堆内存（如JVM元数据、线程栈、代码缓存等）以及其他可能运行在相同节点上的进程。通常建议为系统预留容器总内存的20%-30%。

注意：实际配置时，务必结合应用的实际监控数据和运行情况进行调整，确保资源的高效利用和应用的稳定运行。