曾经我对于linux的内存管理是一片空白和很多疑问,不知道那是什么玩意儿,后来在一位资深友人的指导下,慢慢了解内存管理的重要性,并普及了一些知识。在新版的内核中似乎对于内存管理的疑问有比较新的解决方法。下面就借鉴一些方法,来学习下。
当在linux下 频繁存取文件后,物理内存会很快被用光,当程序结束后,内存不会被正常释放,而是一直作为caching。这个问题,似乎有不少人在问,不过都没有看到有什么很好的解决方法。那么,我们来借鉴并探讨下友人所整理的方法。
一、通常情况
先来探讨free 命令:
引用
- [root@localhost ~]# free -m
- total used free shared buffers cached
- Mem: 1804 205 1599 0 14 145
- -/+ buffers/cache: 46 1758
- Swap: 3615 0 3615
其中:
total 内存总数
|
可用的memory=free mermory+buffers+cached
有了这个基础后,可以得知,我现在used为205M,free为1599M,buffers为14M,cached为145M。那么我们来看看,如果我执行复制文件,内存会发生什么变化。
- [root@localhost /]# cp -r /etc ~/tmp
- [root@localhost ~]# free -m
- total used free shared buffers cached
- Mem: 1804 507 1296 0 19 428
- -/+ buffers/cache: 59 1745
- Swap: 3615 0 3615
当我命令执行完毕后,Used 507M,free为1296M,buffers为19M,cached为428M。基本都被cached吃掉。也不必紧张,这是为了提高文件读取效率的做法。
为了提高磁盘存取的效率,linux做了一些精心的审计,除了对dentry进行缓存(用于VFS,加速文件路径名到inode的转换),还采取了两种主要cache方式:buffer cache和page cache。前者针对磁盘块的读写,后者针对inode的读写。这些cache有效缩短了I/O系统调用(比如read ,write,getdents)的时间。
那么有人会说过一段时间,linux会自动释放掉所用的内存。等待一段时间后,我们再来用free检查,看是否释放掉了内存。
- [root@localhost ~]# free -m
- total used free shared buffers cached
- Mem: 1804 507 1297 0 20 428
- -/+ buffers/cache: 58 1745
- Swap: 3615 0 3615
好像没有任何变化。(实际情况下,内存的管理还与swap有关)
那么,我们能否手动释放掉这些内存呢?给你的答案是可以实现的。
二、手动释放内存。
/proc是一个虚拟文件系统,我们可以通过对它的读写操作作为与kernel实体间进行通信的一种手段。也就是说可以通过修改/proc中的文件,来对当前kernel的行为做出调整。那么我们可以通过调整/proc/sys/vm/drop_caches来释放内存。操作如下:
- [root@localhost ~]# cat /proc/sys/vm/drop_caches
- 0
首先,/proc/sys/vm/drop_caches的值,默认为0
- [root@localhost ~]# sync
手动执行sync命令(描述:sync命令运行sync子例程。如果必须停止系统,则运行sync命令以确保的文件的完整性。sync命令将所有未写的系统缓冲区写到磁盘中,包含已修改的i-node/以延迟的块I/o和读写映射文件)
- [root@localhost ~]# echo 3 > /proc/sys/vm/drop_caches
- [root@localhost ~]# cat /proc/sys/vm/drop_caches
- 3
将/proc/sys/vm/drop_caches值为3
[root@localhost ~]# free -m
total used free shared buffers cached
Mem: 1804 53 1750 0 1 11
-/+ buffers/cache: 41 1763
Swap: 3615 0 3615
再来运行free命令,会发现现在的used 为53M ,free 为1750M,buffers为1M,cached为11M。从以上的数据我们可以得出一个结论buffers 和cached得到了有效的释放。
- /proc/sys/vm/drop_caches (since Linux 2.6.16)
- Writing to this file causes the kernel to drop clean caches,
- dentries and inodes from memory, causing that memory to become
- free.
- To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to
- free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;
- to free pagecache, dentries and inodes, use echo 3 >
- /proc/sys/vm/drop_caches.
- Because this is a non-destructive operation and dirty objects
- are not freeable, the user should run sync first.
三、专家观点
上述文章就长期以来很多用户对linux内存管理方面的疑问
上述文章就长期以来很多用户对Linux内存管理方面的疑问,给出了一个比较“直观”的回复,我更觉得有点像是核心开发小组的妥协。
对于是否需要使用这个值,或向用户提及这个值,我是有保留意见的:
2、若对于系统内存是否够用的观察,我还是原意去看swap的使用率和si/so两个值的大小;
用户常见的疑问是,为什么free这么小,是否关闭应用后内存没有释放?
但实际上,我们都知道这是因为Linux对内存的管理与Windows不同,free小并不是说内存不够用了,应该看的是free的第二行最后一个值:
- -/+ buffers/cache: 41 1763
这才是系统可用的内存大小。
实际项目中告诉我们,如果因为是应用有像内存泄露、溢出的问题,从swap的使用情况是可以比较快速可以判断的,但free上面反而比较难查看。
相反,如果在这个时候,我们告诉用户,修改系统的一个值,“可以”释放内存,free就大了。用户会怎么想?不会觉得操作系统“有问题”吗?
所以说,我觉得既然核心是可以快速清空buffer或cache,也不难做到(这从上面的操作中可以明显看到),但核心并没有这样做(默认值是0),我们就不应该随便去改变它。
一般情况下,应用在系统上稳定运行了,free值也会保持在一个稳定值的,虽然看上去可能比较小。
当发生内存不足、应用获取不到可用内存、OOM错误等问题时,还是更应该去分析应用方面的原因,如用户量太大导致内存不足、发生应用内存溢出等情况,否则,清空buffer,强制腾出free的大小,可能只是把问题给暂时屏蔽了。
我觉得,排除内存不足的情况外,除非是在软件开发阶段,需要临时清掉buffer,以判断应用的内存使用情况;或应用已经不再提供支持,即使应用对内存的时候确实有问题,而且无法避免的情况下,才考虑定时清空buffer。(可惜,这样的应用通常都是运行在老的操作系统版本上,上面的操作也解决不了)。O(∩_∩)O哈哈~
转载于:https://blog.51cto.com/redzgm1988/975150