记一次解决缓存不释放导致内存耗光问题

1 前言

通过脚本备份数据和系统,笔者遇到两项缓存过高不释放而导致内存使用过高问题,Zabbix截图如下,

- 第一次是由每小时往挂载的Window共享里面存放备份文件引起

- 第二次是由每周备份系统过度地频繁读写文件系统引起缓存不释放引起

2 挂载Window共享备份引发的缓存问题

2.1 问题描述

挂载Window的共享成为Linux服务器的备份目录,发现备份后缓存过高,挂载范例如下,

mount -t cifs -o username=user1%pwd1 //backupSer/backup$ /backup/

2.2 排查方法

1)使用free命令可以发现cached占用情况,

free -m

显示如下:

             total       used       free     shared    buffers     cached
Mem:          7872       7732        139          0        190       6312
-/+ buffers/cache:       1229       6642
Swap:         4047          0       4047

注:留意cached项非常高

2)进一步的,使用slabtop可以发现cifs模块占用了大量的缓存(忘记截图保留了……O(∩_∩)O哈哈~,见谅哈!)

slabtop

注:查看SIZE和NAME项

2.3 排查故障

尝试手动卸载发现缓存被释放

umount /backup

2.4 解决方案

改用autofs去按需要自动挂载和卸载(非本文核心内容,这里不详述,自己研究)

3 频繁读写文件系统引发的Cache问题

3.1 问题描述

用tar命令备份系统,由于频繁读写文件系统,物理内存占用不被释放

3.2 排查方法

1)查看缓存占用情况

free -m

显示如下:

             total       used       free     shared    buffers     cached
Mem:          7872       7732        139          0        190       6312
-/+ buffers/cache:       1229       6642
Swap:         4047          0       4047

2)进一步的,使用slabtop没有发现占用了大量缓存的模块

3.3 补充知识

free -m打印的结果,

             total       used       free     shared    buffers     cached
Mem:          7872       7732        139          0        190       6312
-/+ buffers/cache:       1229       6642
Swap:         4047          0       4047

如上所示,

cached项反映的是pagecache的使用情况

buffers项反映的是inode和dentry等文件系统metadata的使用情况

网络上有3种释放方法:

#释放pagecache
echo 1 > /proc/sys/vm/drop_caches  

#释放inode和dentry等metadata  
echo 2 > /proc/sys/vm/drop_caches  

#释放pagecache和inode/dentry
echo 3 > /proc/sys/vm/drop_caches

3.4 解决方案

sync
sync
sync
echo 1 > /proc/sys/vm/drop_caches

注:建议不要释放inode和dentry,笔者在CentOS 6.8中尝试使用过,会导致虚拟机死机(当然,这有可能是个特例)

参考文献:

======================================================

http://blog.csdn.net/fall221/article/details/46290563

http://www.cnblogs.com/panfeng412/p/drop-caches-under-linux-system.html

时间: 2024-11-05 18:35:45

记一次解决缓存不释放导致内存耗光问题的相关文章

memset函数导致内存泄露的问题

我们一般常说的内存泄漏是指堆内存的泄漏.程序从堆中分配的内存使用完毕后必须显式释放,否则这块内存就不能被再次使用,即这块内存泄漏了.内存泄漏导致软件在运行过程中占用越来越多的内存,程序的效率会越来越低,从而影响用户的体验,失去市场竞争力.  为了预防内存泄漏我们要求程序使用malloc.new等函数从堆中分配的内存必须在使用完后调用free.delete函数释放该内存.但是如果指向该内存指针的值被修改了,不再指向该内存了,那么即使调用free.delete函数也不会释放该内存,memset函数

应对Memcached缓存失效,导致高并发查询DB的几种思路

原文地址: http://blog.csdn.net/hengyunabc/article/details/20735701 当Memcached缓存失效时,容易出现高并发的查询DB,导致DB压力骤然上升. 这篇blog主要是探讨如何在缓存将要失效时,及时地更新缓存,而不是如何在缓存失效之后,如何防止高并发的DB查询. 个人认为,当缓存将要失效时,及时地把新的数据刷到memcached里,这个是解决缓存失效瞬间高并发查DB的最好方法.那么如何及时地知道缓存将要失效? 解决这个问题有几种思路: 比

POI读写大数据量excel,解决超过几万行而导致内存溢出的问题

1. Excel2003与Excel2007 两个版本的最大行数和列数不同,2003版最大行数是65536行,最大列数是256列,2007版及以后的版本最大行数是1048576行,最大列数是16384列. excel2003是以二进制的方式存储,这种格式不易被其他软件读取使用:而excel2007采用了基于XML的ooxml开放文档标准,ooxml使用XML和ZIP技术结合进行文件存储,XML是一个基于文本的格式,而且ZIP容器支持内容的压缩,所以其一大优势是可以大大减小文件的尺寸. 2. 大批

内存模型是怎么解决缓存一致性的?

前言 在再有人问你Java内存模型是什么,就把这篇文章发给他.这篇文章中,我们介绍过关于Java内容模型的来龙去脉. 我们在文章中提到过,由于CPU和主存的处理速度上存在一定差别,为了匹配这种差距,提升计算机能力,人们在CPU和主存之间增加了多层高速缓存.每个CPU会有L1.L2甚至L3缓存,在多核计算机中会有多个CPU,那么就会存在多套缓存,那么这多套缓存之间的数据就可能出现不一致的现象.为了解决这个问题,有了内存模型.内存模型定义了共享内存系统中多线程程序读写操作行为的规范.通过这些规则来规

记一次由于引用第三方服务导致的GC overhead limit exceeded异常

最近笔者遇到一个问题  监控平台忽然告警 GC overhead limit exceeded 这个异常 第一反应估计是堆溢出了.于是各种各种jmap  jstack下载堆栈文件和堆日志文件. 以下是线程堆栈dump下来的日志文件 p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px "Helvetica Neue"; color: #0433ff } span.s1 { font: 12.0px ".PingFang SC

Android性能调优:记一次解决OOM的经历

OOM OOM(Out Of Memory)是Android应用开发中相信每个人都遇到过的问题,而OOM在crash log中的stack trace一般没有实际意义,因为是在分配内存的时候才会抛出OOM异常,而这个时候的stack trace和OOM的原因没有任何关系.所以OOM问题的定位和分析就需要多花费一些功夫. 下面,我就结合一个例子,来讲讲怎么定位OOM问题. 问题 在程序员们把代码写完,基本流程测试无误,准备要发布的时候,云测的结果却是:一大波OOM异常.没办法,只好重新打开电脑定位

修改DNS域名转发器解决IP地址解析错误导致的网站不能访问

修改DNS域名转发器解决IP地址解析错误导致的网站不能访问 首先谢谢同事林路的指导,才能顺利解决问题 打开网站,访问一个域名,DNS解析到错误的IP地址,那么将不能正确访问该网站 1.使用8.8.8.8(google 公用dns定位本地dns解析和google解析),这里是zh.wikipedia.org ping zh.wikipedia.org     159.106.121.75(这个是很多dns异常解析的地址) nslookup -qt zh.wikipedia.org 8.8.8.8

AngularJS进阶(二十八)解决AngualrJS页面刷新导致异常显示问题

解决AngualrJS页面刷新导致异常显示问题 绪 俗话说,细节决定成败,编程亦是如此.编程过程中我们可能会不自觉的忽视一些细节问题,殊不知,这些细节正是导致页面显示出现问题的地方.今略举一例,与君共勉之. 页面正常加载后,显示如下: 按F5刷新之后,页面如下所示: 很明显,页面显示出现了异常.回过头再看看Chrome的错误提示, 具体代码如下: 正是以上代码导致了错误的发生. 追根溯源 让我们回顾一下,错误到底是如何发生的.正常加载情况下,页面正常显示很容易理解,程序是按照既定的数据流走的.但

如何解决url传参导致错误问题

如何解决url传参导致错误问题:如果使用url传并且参数中含有特殊字符的话,那么就会导致一些错误,下面就来介绍一下如何解决此问题.方法很简单,只要使用encodeURI ()函数进行编码即可.如果得到原来的字符串,使用decodeURI()函数即可,这里就不多介绍了.更多相关内容可以参阅js的escape.encodeURI和encodeURIComponent的区别一章节. 原文地址是:http://www.softwhy.com/forum.php?mod=viewthread&tid=97