免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 印随
打印 上一主题 下一主题

[C] mmap内存占用问题 [复制链接]

论坛徽章:
0
41 [报告]
发表于 2008-04-02 21:36 |只看该作者

论坛徽章:
0
42 [报告]
发表于 2008-04-02 22:08 |只看该作者
这是Linux Redhat allocator作者的website: http://www.malloc.de/en/

其中关于mmap的注释:
DEFAULT_MMAP_THRESHOLD       default: 256K
      Also settable using mallopt(M_MMAP_THRESHOLD, x)
  The request size threshold for using MMAP to directly service a
  request. Requests of at least this size that cannot be allocated
  using already-existing space will be serviced via mmap.  (If enough
  normal freed space already exists it is used instead.)  Using mmap
  segregates relatively large chunks of memory so that they can be
  individually obtained and released from the host system. A request
  serviced through mmap is never reused by any other request (at least
  not directly; the system may just so happen to remap successive
  requests to the same locations).  Segregating space in this way has
  the benefits that: Mmapped space can always be individually released
  back to the system, which helps keep the system level memory demands
  of a long-lived program low.  Also, mapped memory doesn't become
  `locked' between other chunks, as can happen with normally allocated
  chunks, which means that even trimming via malloc_trim would not
  release them.  However, it has the disadvantage that the space
  cannot be reclaimed, consolidated, and then used to service later
  requests, as happens with normal chunks.  The advantages of mmap
  nearly always outweigh disadvantages for "large" chunks, but the
  value of "large" may vary across systems.  The default is an
  empirically derived value that works well in most systems. You can
  disable mmap by setting to MAX_SIZE_T.


brk/sbrk 是mmap的特例。

mmap映射一个1G 的文件,最终会用1G的RAM。(direct IO 例外)。

论坛徽章:
0
43 [报告]
发表于 2008-04-02 22:14 |只看该作者
mmap映射一个1G 的文件,最终会用1G的RAM。

对的.
实际和malloc一样的.

你mmap一个1G文件, 用内存是0.
然后, 你开始将每一PAGE(1G/4096个总共)的开始都写上一个字符, 写完后, 1G物理内存用掉了.
马上free -m会看到效应.





原帖由 Alligator27 于 2008-4-2 22:08 发表
这是Linux Redhat allocator作者的website: http://www.malloc.de/en/

其中关于mmap的注释:


brk/sbrk 是mmap的特例。

mmap映射一个1G 的文件,最终会用1G的RAM。(direct IO 例外)。

论坛徽章:
0
44 [报告]
发表于 2008-04-03 10:10 |只看该作者
我的系统是ubuntu,物理内存为1G

我刚才做了一个试验,不管是读还是写
映射1G的文件,最终会(大概)占用1G RAM(剩余内存直线减小,到最后会有一个小回升,可能是系统发现内存不够用,把一些临时占用的内存释放)

,系统剩余内存一直减少到十几M的状态,十几M剩余内存保持不变

这十几M内存为什么不被占用?(在我的系统中是13M)

论坛徽章:
0
45 [报告]
发表于 2008-04-03 10:16 |只看该作者
系统会保留最小的物理内存用做基本的工作.

实在不够了就交换出.

再不够了就杀死某些倒霉的进程.


原帖由 印随 于 2008-4-3 10:10 发表
我的系统是ubuntu,物理内存为1G

我刚才做了一个试验,不管是读还是写
映射1G的文件,最终会(大概)占用1G RAM(剩余内存直线减小,到最后会有一个小回升,可能是系统发现内存不够用,把一些临时占用的内存 ...

论坛徽章:
0
46 [报告]
发表于 2008-04-03 10:19 |只看该作者
原帖由 思一克 于 2008-4-3 10:16 发表
系统会保留最小的物理内存用做基本的工作.

实在不够了就交换出.

再不够了就杀死某些倒霉的进程.




某些倒霉进程?是不是在指那些僵尸进程

论坛徽章:
0
47 [报告]
发表于 2008-04-03 10:22 |只看该作者
不是. 杀死的是正在运行的普通进程. 千万不要让机器到这地步.

这个功能在LINUX中叫OOM KILLER (out of memory 杀手).

原帖由 印随 于 2008-4-3 10:19 发表


某些倒霉进程?是不是在指那些僵尸进程

论坛徽章:
0
48 [报告]
发表于 2008-04-03 10:27 |只看该作者
那我想在程序中一直要访问一个1G的文件,
有没有好办法?
我的办法是1:一次性全部映射(缺点是内存占用太大)
                    2:分页映射(页面管理繁琐)

论坛徽章:
0
49 [报告]
发表于 2008-04-03 10:28 |只看该作者
不需要用mmap. 就是用seek, read, write就可以了.

原帖由 印随 于 2008-4-3 10:27 发表
那我想在程序中一直要访问一个1G的文件,
有没有好办法?
我的办法是1:一次性全部映射(缺点是内存占用太大)
                    2:分页映射(页面管理繁琐)

论坛徽章:
0
50 [报告]
发表于 2008-04-03 11:11 |只看该作者
是我理解有问题

int main(int argc, char* argv[])
{
        int fd = open("./futex",O_RDWR|O_CREAT, 0777);
        int fd2 = open("./futex2",O_RDWR|O_CREAT, 0777);

        lseek(fd,G,SEEK_SET);
        write(fd, "0", 1);

        lseek(fd2,G,SEEK_SET);
        write(fd2, "0", 1);
        char *base = mmap(NULL,G,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
        char *base2 = mmap(NULL,G,PROT_READ|PROT_WRITE,MAP_SHARED,fd2,0);
        char *p;

        for (p = base; p < base + G; p += 4096)
                *p = 'a';

        for (p = base2; p < base + G; p += 4096)
                *p = 'a';

        return 0;
}
现象是总是占用内存在700M左右,应该是系统会从它占用的内存中回收
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP