pod的内存一直增加原因与解决

本文探讨了阿里云监控中Java应用内存使用超过配置,尽管JVM xmx为3G,但实际占用7G的问题。重点在于理解pod中缓存内存持续增长的原因,并提供了手动清理缓存和定期任务的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

现象描述

阿里云监控上的内存使用是6.8G,针对channel的内存配置,内存限制是8G,内存使用率为85%
所以告警了。
但是jvm的xmx配置是3G,正常情况下pod占用的内存4-5G应该就足够了,但是实际却使用了7G的内存,为什么?

在虚拟容器中:
root@coding-editor-channel-84dc87b897-lvfvz:/app# free -m
              total        used        free      shared  buff/cache   available
Mem:          62097       20594        7384        3078       34119       38356

说明:
共62G内存
使用了20G
剩余7G
共享3G
缓存占用34G
实际可用38G


top指令:

cat /proc/memoryinfo查看
https://segmentfault.com/a/1190000022518282

巨坑:pod中所有top、free、cat /proc/memoryinfo结果都是机器的数据,不是pod自身的数据

pod的内存与cpu使用查看方法:
kubectl top pod coding-editor-channel-84dc87b897-lvfvz -n peiyou-xiaohoucode-prod

mazhen@mazhendeMacBook-Pro .kube % kubectl top pod coding-editor-channel-84dc87b897-lvfvz -n peiyou-xiaohoucode-prod

W0207 15:23:13.981693   35658 top_pod.go:140] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME                                     CPU(cores)   MEMORY(bytes)   
coding-editor-channel-84dc87b897-lvfvz   22m          6977Mi   

内存一直增加的原因

 https://www.jianshu.com/p/c0d5a40fe9e8

Linux下经常会遇到buff/cache内存占用过多问题,尤其是使用云主机的时候最严重,由于很多是虚拟内存,因此如果buff/cache占用过大的,free空闲内存就很少,影响使用;

通常内存关系是:

普通机器:total=used+free

虚拟机器:total=used+free+buff/cache

pod中java进程占用的内存基于xmx参数机会是固定的,但是关于缓存内存:由于没有达到limit的,所以缓存一直不会释放,缓存占用的内存会一直增加,所以pod占用的内存也会一直增加。


解决:清理缓存

 手动释放缓存对内存的占用:

可以使用一下命令去清除一下cache内存

1)注意:先执行sync,再修改/proc/sys/vm/drop_caches,含义:运行sync将dirty的内容写回硬盘,防止数据丢失。

echo 1 > /proc/sys/vm/drop_caches

echo 2 > /proc/sys/vm/drop_caches

echo 3 > /proc/sys/vm/drop_caches

drop_caches的值可以是0-3之间的数字,代表不同的含义: 0:不释放(系统默认值) 1:释放页缓存 2:释放dentries和inodes 3:释放所有缓存

或者定时任务清除缓存:

Linux的buff/cache占用内存过高解决方法_一条很咸的的博客-优快云博客_buff/cache过高https://blog.youkuaiyun.com/weixin_47758362/article/details/107513091

实际操作步骤

在pod所在机器上操作步骤如下:
[admin@iZ8vbcshuo9swn0k3d5zgmZ ~]$ whoami
admin
[admin@iZ8vbcshuo9swn0k3d5zgmZ ~]$ sudo -s
[root@iZ8vbcshuo9swn0k3d5zgmZ admin]# free -m
              total        used        free      shared  buff/cache   available
Mem:          62097        8194       24868        3079       29034       51256
Swap:             0           0           0
[root@iZ8vbcshuo9swn0k3d5zgmZ admin]# sync
[root@iZ8vbcshuo9swn0k3d5zgmZ admin]# cat /proc/sys/vm/drop_caches
0
[root@iZ8vbcshuo9swn0k3d5zgmZ admin]# echo 1 > /proc/sys/vm/drop_caches
[root@iZ8vbcshuo9swn0k3d5zgmZ admin]# free -m
              total        used        free      shared  buff/cache   available
Mem:          62097        8202       46740        3079        7154       51247
Swap:             0           0           0

pod的内存占用情况:6.9G --> 4.8G,详情如下:
mazhen@mazhendeMacBook-Pro .kube % kubectl top pod coding-editor-channel-84dc87b897-lvfvz -n peiyou-xiaohoucode-prod

W0207 15:23:13.981693   35658 top_pod.go:140] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME                                     CPU(cores)   MEMORY(bytes)   
coding-editor-channel-84dc87b897-lvfvz   22m          6977Mi          
mazhen@mazhendeMacBook-Pro .kube % kubectl top pod coding-editor-channel-84dc87b897-lvfvz -n peiyou-xiaohoucode-prod

W0207 15:35:45.340326   36032 top_pod.go:140] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME                                     CPU(cores)   MEMORY(bytes)   
coding-editor-channel-84dc87b897-lvfvz   18m          4485Mi  


 

当 Kubernetes 中的 Pod 处于 `CrashLoopBackOff` 状态时,通常意味着容器在启动后立即崩溃,然后不断地重启,形成一个无限循环。这种情况可能由多种原因引起,包括但不限于: 1. **容器镜像问题**:镜像可能存在启动时的错误,如配置错误、代码bug、依赖缺失或版本不兼容等。 2. **资源不足**:如果Pod的资源请求(CPU、内存)超过了集群中可用的资源,也会导致Pod进入 `CrashLoopBackOff`。 3. **环境变量或配置文件**:环境变量设置不正确,或者配置文件存在问题可能导致应用无法正常初始化。 4. **日志错误**:查看Pod的 logs 可能会发现错误信息,这些信息会帮助定位问题所在。 5. **卷挂载问题**:如果容器依赖外部卷(如持久化存储),卷挂载失败也会造成这种情况。 解决方法可以分为以下几个步骤: - **检查日志**:使用 `kubectl logs <pod-name>` 查看容器的日志输出,找出错误的根源。 - **审查配置**:检查 pod 的定义和容器的启动命令,确保一切配置正确无误。 - **资源调整**:如果资源不足,根据需要调整 Pod 的资源请求和限制。 - **修复镜像**:如果是镜像问题,更新镜像或者修复启动脚本。 - **检查网络**:确认网络配置没有问题,特别是对于需要网络访问的应用。 - **等待事件解决**:有时候,短暂的故障会被自动恢复,可以稍等片刻再观察。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值