linux内存小记1

这应该是一个操作系统调度问题，而不是一个编程问题，我在Linux内核2.6.9(内存256MB)下做了测试：
按照LZ的那种写文件方式，确实有这个现象，不过top监控是进程本身的虚拟内存和物理内存消耗很少，基本很稳定，但是vmstat跟踪系统状态结果如下
[root@localhost ~]# vmstat 60
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
 2 0 224 116320 4780 35520 0 0 59 125 537 216 3 5 91 1
 0 0 224 94288 5096 57304 0 0 0 371 1072 486 5 6 88 1
 0 0 224 70192 5432 81148 0 0 0 418 1057 351 2 3 95 0
 0 0 224 46312 5764 104736 0 0 0 412 1058 326 1 3 96 0
 0 0 224 21892 6284 128656 0 0 8 430 1071 395 2 3 94 1
 0 0 224 18156 5264 133056 0 0 47 414 1087 531 3 4 91 1
 0 0 224 17312 5284 133816 0 0 1 421 1132 574 3 4 92 0
 0 0 224 18620 5252 132288 0 0 0 417 1058 372 2 3 95 0
可以看到memory下free和cache的变化趋势（间隔60秒），也就是系统空闲内存都用来做cache了，以提高写入磁盘的性能
从http://www.faqs.org/docs/linux_admin/buffer-cache.html摘录部分段落也说明了该问题
  If the cache is of a fixed size, it is not very good to have it too big, either, because that might make the free memory too small and cause swapping (which is also slow). To make the most efficient use of real memory, Linux automatically uses all free RAM for buffer cache, but also automatically makes the cache smaller when programs need more memory.
  Under Linux, you do not need to do anything to make use of the cache, it happens completely automatically. Except for following the proper procedures for shutdown and removing floppies, you do not need to worry about it. 

 

另外，下面是我的一点理解，大家帮我看看我理解的有没有错误： （1）O_SYNC标志设定是体现write（）操作的同步问题。如果设定了该标志，那么只有在写的内容的确从物理上写入存储设备，那么write（）才返回； （2）对我们经常看见的空间理解     用户空间（user-space） | 内核空间（incore-space） | Page cache | disk cache | disk | ram buffer     1.用户空间：fwrite（）内申请的缓存内存空间。因为用户可以通过setbuffer()等函数对其进行设定；   2.内核空间：write（）内申请的缓存内存空间。这个是OS为写操作申请的内存，对用户来说不可见。   3、4.Cache: 理解不是很深刻。不知道是物理cache还是可以占用内存的cache；   5.disk：这个就不说了。   6.buffer: 不是很理解，感觉它和Page cache是一个东西 （3）几个同步函数   1.fflush():The function fflush() forces a write of all user-space buffered data for the given output or update stream    via the stream's underlying write function. The open status of the stream is unaffected.    我的理解是该函数将fwrite（）里面的缓存内容强行压入底层（内核空间？cache？disk？）。至于压倒哪里就不明白了，我猜是压入到了   write（）的内核空间。   2.fsync(): fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file    referred to by the file descriptor fd to the disk device (or other permanent storage device) where that file    resides.    我的理解是该函数将write（）里面内核空间（修改的部分）压入到磁盘设备。但是这里的buffer cache pages又不明白和内核空间的关系了

3	#21楼 得分：0回复于：2008-08-20 11:36:44 也不是很理解，但buffer跟cache不应该是一个东西, buffer是IO的范畴，cache的页面替换的范畴，两个不相干的概念

#22楼 得分：0回复于：2008-08-20 15:01:04 看完15楼的连接终于明白了原因了。真是十分的感谢！！！！！ －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 重新整理一下我的思路： （1）写操作的过程空间   用户空间（user-space） ¦ 内核空间（incore-space） ¦ buffer cache ¦ disk ¦     1.用户空间：fwrite（）内申请的缓存内存空间。因为用户可以通过setbuffer()等函数对其进行设定；    2.内核空间：write（）内申请的缓存内存空间。这个是OS为写操作申请的内存，对用户来说不可见。    3.buffer cache: 这个东东是造成我们内存减少的主要原因。不是我们的过错，是OS的特性；   5.disk：这个就不说了。   （2）同步问题   即使我们在fwrite（）、write（）后面使用了sync（），fsync（）等同步操作，在内存中也会保留buffer cache的，所以内存不会减少... －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 不过有个新问题，在存在这中情况下我们怎么查看我们程序的内存泄漏（本帖的出处就是我本来想看内存是否泄漏，才发现fwrite()的这个现象）？ 莫非我们要将程序的所有“写”操作都屏蔽掉才能看出来是否内存泄漏了？     用错了工具。用valgrind、mtrace等来看是否有内存泄漏。如果用-g选项编译，可以给出具体的代码位置。 不能用sysinfo的返回信息判断是否有内存泄漏。freeram是free物理内存，所有的进程，包括内核都使用这些内存，所以它的数值变化不能说明你的进程的任何问题。fwrite的现象是内核为了提升disk访问性能，进行了page cache，不需要多虑。   #26楼 得分：0回复于：2008-08-21 14:16:46 好了，谢谢大家参与。 封贴了...