mmap内存占用问题

印随

剩余内存我指的是   free  mem，  



分段映射1G文件，实现分段访问,  每段为1M
for（）
{
     mmap();
     访问;
     munmap();
}

过程是我把1G文件完全访问一遍，
free -m    发现内存就基本耗尽


我认为不应该是这样的，mmap始终只在使用1M内存

[ 本帖最后由 印随 于 2008-4-3 13:25 编辑 ]

flw

许多年以前，这个论坛流行一句很自负很自豪很牛逼的话：
内存就是让用的……

[ 本帖最后由 flw 于 2008-4-3 13:26 编辑 ]

印随

原帖由 flw 于 2008-4-3 13:24 发表
几年前，这个论坛流行一句很自负很自豪很牛逼的话：
内存就是让用的……

我认为不应该是这样的，mmap始终只在使用1M内存



决定不用mmap了，还是文件IO简单，虽然麻烦一点

[ 本帖最后由 印随 于 2008-4-3 13:39 编辑 ]

mingyanguo

即使unmap，那些物理内存也不一定立即释放，如果你想释放物理内存，可以看看madvise(2)

思一克

所以,尽量不要用mmap映射大文件. 尤其是不要用在常驻内存的程序中.

flw

原帖由 思一克 于 2008-4-3 15:06 发表
所以,尽量不要用mmap映射大文件. 尤其是不要用在常驻内存的程序中.

分段映射呢？
比如每次只映射一小部分。

flw2

原帖由 flw 于 2008-4-3 15:07 发表

分段映射呢？
比如每次只映射一小部分。

我的理解是没关系， 那段英文也提到了，说可以分段释放

很多不好daemon通常会有个buf，然后越来越大
char data[10M]；
然后保持最大在10M，如果超过就删除某些旧的数据， 但是这个后果就是某段时间过后，内存占用大于10M，即使daemon只是偶尔需要10M
所以可以mmap一个，然后释放，这样就可把物理内存真正的归还给系统，在需要时增加一些，对于一些偶尔要求大内存块，但是通常却不需要的daemon很好

思一克

分段, 是可以的, 但是意义也不是很大.

事实上MMAP和普通的read, write不是什么时候都有速度优势的. 因为文件最终要写磁盘, 而磁盘是外部设备, 速度的关键在这里.

如真想用, 对于大的文件(比物理内存大许多的), 应该考虑分段.

反正一次不分段可能是不良的程序, 和malloc一个巨大内存然后不断随机存取一样占用内存.

如果读写的仅仅是文件中的一小块地方, 不分段也可以, 对于没有读写的地方,mmap后并没有真正使用物理内存

原帖由 flw 于 2008-4-3 15:07 发表

分段映射呢？
比如每次只映射一小部分。

flw

原帖由 思一克 于 2008-4-3 15:16 发表
如果读写的仅仅是文件中的一小块地方, 不分段也可以, 对于没有读写的地方,mmap后并没有真正使用物理内存

但是占地址空间呀。
因此不分段的话，程序就只能处理不超过 2G 的文件，比如 19 个 100M，或者 5 个 390M。
我的 FTP 上传程序目前就有这个限制。

另外我觉得我使用 mmap 一方面是可能会快一点，另一方面主要还是觉得编码会简单些（我是多线程共享句柄）。
当然了，如果分段的话，编码简单这个优势就不是很明显了。

印随

采用分段
简单使用munmap，  释放一个分段， 好像没有什么效果
不能释放内存

[ 本帖最后由 印随 于 2008-4-3 15:34 编辑 ]