centos 内存回收?centos7卸载软件命令
cgroup 内存泄露问题排查记录
出现内存泄漏的主机为集群机器,运行时间约5天,内存使用超90%,其上运行集群管理软件和 docker并执行测试脚本反复启停容器。
长时间运行后,集群主机内存占用逐渐增加,出现应用 OOM现象。
而实际查看时发现主机内存总占用高,但应用实际占用内存低或未见显著异常。
可以看到内存占用 83.6%,而实际top显示的内存占用最高也才 0.6%没有占用内存过高的应用。
内存占用除了用户应用占用还有内核占用,遂查看内核内存占用。
使用linux文件系统接口查看
可以看到占用超高的项目为 slab内核占用:
继续查看内核详细占用,按照缓存大小进行排序
可以看到此处:
kmalloc-2048,kmalloc-4096,kernfs_node_cache,kmalloc-1024,kmalloc-192,kmalloc-512均占用较高,对比了正常主机,已经严重超过正常值。
如果是内核缓存过高则可以尝试进行内核缓存释放:
但执行上述操作后,内存占用依旧无显著下降,也符合上面看到的 SUnreclaim: 2447108 kB//slab不可回收内存大小。这部分内存不能被释放。
kmalloc为内核进行分配的内存,参考价值较大的为 kernfs_node_cache占用高,遂搜索该项是作何作用。
很明显,该现象为内核占用严重超标,于是在搜索时加入了 memory leak关键字,很快发现了该 Issues docker-run--memory slab cache leak on centos7
该 issue表示 centos7在反复运行 docker run--rm--memory 1g hello-world时存在明显的内核内存占用升高,且无法被释放。且现象和当前现象一致。
最终指向内kernel c group内存泄露问题 slab leak causing a crash when using kmem control group
大致原因是在 3.10内核上如果使用了 kmem limit参数,会导致cgroup回收时无法释放部分已分配内存。至于更深入的了解,还需要其他时间,先解决目前的问题。
原因大概确定,为了再次确定这个问题,如果能够通过上述手段复则可以确定是该问题。
在一台仅运行docker的机器上执行上述语句,查看 slab内存占用,可以看见内存占用明显上升。且最终表现和已有环境上的问题一致,总内存占用高,用户态内存占用低,内核内存占用高且无法被释放。
既然是内核问题,且知道了明确复现路径,则可以通过两种方式进行解决:
最终,进过测试后,选择了更换内核版本,将使用 Ubuntu 18.04作为新的操作系统。
Linux内核使用层次化内存管理的方法,每一层解决不同的问题,从下至上的关键部分如下:
slab是Linux操作系统的一种内存分配机制。其工作是针对一些经常分配并释放的对象,如进程描述符等,这些对象的大小一般比较小,如果直接采用伙伴系统来进行分配和释放,不仅会造成大量的内碎片,而且处理速度也太慢。而slab分配器是基于对象进行管理的,相同类型的对象归为一类(如进程描述符就是一类),每当要申请这样一个对象,slab分配器就从一个slab列表中分配一个这样大小的单元出去,而当要释放时,将其重新保存在该列表中,而不是直接返回给伙伴系统,从而避免这些内碎片。slab分配器并不丢弃已分配的对象,而是释放并把它们保存在内存中。当以后又要请求新的对象时,就可以从内存直接获取而不用重复初始化。
Slab导致的占用内存过高,Slab可以对可回收缓存手动释放,操作如下:
其中drop_caches的4个值有如下含义:
CentOS技巧减小Linuxswap分区的方法
用虚拟机玩Linux时经常发生Linux硬盘空间不足的情况,而宿主机硬盘空间又吃紧,怎么办?
很多童鞋给Linux分配的硬盘是8G,而安装Linux时采用默认分区方式的话swap分区有2G。swap分区即交换分区,类似于Windows的虚拟内存pagefile.sys。当内存不足时,把一部分硬盘空间虚拟成内存使用。而内存够用时则排不上用场。
对于实体机Linux,这2G的swap空间一般算不了什么,但对硬盘只有8G的虚拟机Linux来说,2G就很宝贵了。所以——减小Linux swap分区收回空间。
减小swap分区的方法:
1、先“df-h”和“fdisk- l”命令查看一下当前分区情况,如图。根分区为5.5G。
图中/dev/mapper/vg_"hostname"-lv_swap就是swap分区,为2G。swap分区亦可用free命令查看到。
2、用swapoff命令关闭交换分区:
# swapoff/dev/mapper/vg_"hostname"-lv_swap
然后用free命令检查下swap是否变为0了。
3、用lvreduce命令把swap分区减小1500M:
# lvreduce-L-1500M/dev/mapper/vg_"hostname"-lv_swap
输入y,确定,看到提示swap减小至516M。
4、重新把/dev/mapper/vg_"hostname"-lv_swap设置为swap分区:
# mkswap/dev/mapper/vg_"hostname"-lv_swap
5、swapon开启swap分区:
# swapon/dev/mapper/vg_"hostname"-lv_swap
然后用free命令检查下swap是否变为516M了。
扩展根分区把回收的空间利用起来
1、此时回收的1500M是闲置的自由空间,还得将它分配给根分区。还好现在的Linux分区一般是采用LVM分区方式,可以很方便地进行分区的动态扩展,不破坏现有数据。笔者这里是使用图形LVM(Logical Volume Manager)工具进行分区的动态扩展(如果没有安装此工具则需要装一下system-config-lvm的rpm包)。高手亦可在命令行下完成。
# system-config-lvm
展开“逻辑视图”->“lv_root”,点击“编辑属性”。
2、点击“使用剩余”,可以看到5.54G增大至7.0G了。然后“确定”。
3、回到LVM界面,查看到自由空间变为0了。
4、回到命令行模式用“df-h”命令检查一下,可以看到根分区增大至6.9G了。动态扩展无需重启,立即生效,大功告成!
CentOS下top和free命令查看系统中空闲内存的方法
下面介绍使用top和free命令查看系统中空闲内存
所以你执行top命令看到的
[root@linuxzgf~]# top
Mem: 8174492k total, 7124268k used,并不是代表你的应用程序已经使用了7.1的内存,这7.1G是包含了:应用程序内存+缓冲+缓存的内存的,需要用free命令查看.
下面是一个例子(单位是MB):
[root@linuxzgf~]# free-m
total used free shared buffers cached
Mem: 7982 6811 1171 0 350 5114
-/+ buffers/cache: 1346 6636
Swap: 16935 11 16924
[root@linuxzgf~]#
在这里例子中,应用程序只使用了1346MB内存,还有6636MB空闲内存可以使用.
一些简单的计算方法:
物理已用内存=实际已用内存-缓冲-缓存
= 6811M- 350M- 5114M
物理空闲内存=总物理内存-实际已用内存+缓冲+缓存
应用程序可用空闲内存=总物理内存-实际已用内存
应用程序已用内存=实际已用内存-缓冲-缓存
原始解释:转至互联网:
Linux的基本原则是没有资源应该被浪费.因此核心会使用尽可能多的RAM,来缓存来自本地和远程的文件系统的信息.系统做读写操作的时候,会将与当前运行的进程相关的数据尽量存储在RAM里.系统报告的缓存是缓冲和页缓存两者之和.缓存并不是在进程结束的时候被回收(你可能很快会启动另外一个进程,需要同样的数据),而是随需回收比如,当你启动一个需要大量内存的进程时,Linux核心会从内存中回收缓存,将得到的内存分配给新的进程.
有些区域,比如匿名内存映射(mmps)和共享内存区域,它们被报告为缓存,但不是被核心直接释放.一般的缓存不映射到进程的地址空间,仅仅是简单的核心映射,而这些特别的缓存映射到所有挂接到它们上面的进程.