linux有查看和整理内存碎片的工具吗？

lllaaa

原帖由 cugb_cat 于 2008-6-11 20:57 发表

伙伴系统~~~

buddy system分配内存的时候并不能保证物理地址连续的. 尤其是非2的整数次冥的页面数量的时候.需要mmu将这些物理地址不连续的内存块在线性空间上拼接起来.

Strange

libc没有帮我们实现buddy system，自己为了这么点内存去实现一个复杂的内存管理，得不偿失哎

figofuture

照这样说，用java好了！

lllaaa

其实lz说的这个现象是libc的实现问题.

对于内核来说,只知道有程序批发了内存,至于内存是怎么零散的租借给应用程序内核是不知道也不需要关心的.


而且,libc何时真正归还内存给系统是有其策略的.lz根本没有必要如此执着要去看碎片.需要释放的时候libc自然会释放.

程序退出的时候,操作系统会一次性收回所有被批发走的内存.不管这些内存中的一部分是不是被应用程序归还给了libc.

[ 本帖最后由 lllaaa 于 2008-6-12 00:03 编辑 ]

incle

原帖由 Solidus 于 2008-6-10 22:03 发表
linux的内存管理机制我不清楚，实际上win下的所谓内存碎片整理（RAM优化什么的）原理非常简单，申请非常大的内存（把自己的工作集扩张的非常大，导致其他进程（包括被操作系统内核占用的可换出的内存页全部drop ...

如此说来, 像优化大师之类的玩意纯属是骗钱,占空间的东东了?

bigluo

不管linux fans愿不愿相信，glibc使用的dlmalloc还有kernel使用的buddy系统，都是有碎片的，但是我在这里更关注的是dlmalloc所产生的碎片：



这幅图引自Advanced Memory Allocation, 图中灰色和蓝色的交替形成了malloc的内存碎片。当调用free的时候，只有trim space和最靠近trim space的free chunks可以被系统回收。

n        arena        ordblks        smblks        hblks        hblkhd        usmblks        fsmblks        uordblks        fordblks        keepcost
20        270336        36        5        0        0        0        208        117960        152376        100832
40        303104        24        47        0        0        0        1504        127312        175792        133600
60        487424        6        57        0        0        0        1856        241104        246320        134744
80        487424        8        58        0        0        0        2024        283144        204280        134744
100        487424        13        57        0        0        0        1848        238416        249008        134744
120        487424        38        57        0        0        0        1880        243968        243456        134744
140        487424        58        33        0        0        0        1152        248272        239152        134784
160        487424        46        16        0        0        0        592        246880        240544        134784
180        487424        48        17        0        0        0        648        207152        280272        134784
200        487424        56        88        0        0        0        2336        204920        282504        134784
220        487424        78        22        0        0        0        736        201704        285720        134784
240        487424        70        20        0        0        0        744        201816        285608        134784
260        487424        64        18        0        0        0        672        201928        285496        134784
280        487424        62        18        0        0        0        672        202032        285392        134784
300        487424        62        21        0        0        0        768        202128        285296        134784
320        487424        62        18        0        0        0        624        202248        285176        134784
340        487424        58        18        0        0        0        632        202352        285072        134784

这是我们开发的一个程序运行状态下的mallinfo报告，大家可以看看malloc的效率，当n=20的时候，一共分配了arena=270336 bytes, 真正使用的是uordblks=117960. 其他的都是malloc的mem pool, 效率也就40%差不多。

所以我想找一些工具，首先起码能够帮助我动态输出dlmalloc的chunks layout，这样我可以知道到底是哪些内存块造成了最严重的碎片。当然，如果能够发现自动整理的工具，那就更好了。但是看来希望渺茫。

p4apple

同意29楼的说法，
如果需要考虑内存碎片的地方， 就应该自己设计，内存池，自己管理好内存。
在不要的时候， 多虑是没用的。

bigluo

原帖由 p4apple 于 2008-6-12 13:50 发表
同意29楼的说法，
如果需要考虑内存碎片的地方， 就应该自己设计，内存池，自己管理好内存。
在不要的时候， 多虑是没用的。

这样当然是最好了，但是现实当中，至少就我个人而言，所维护的代码70%以上都是别人写的，或者是写的时候没有想到这些问题。等到意识到问题的时候，起码时间上已经不允许再做一个内存管理模块了，只能去通过一些比较间接的方法去降低影响了。

safedead

原帖由 bigluo 于 2008-6-12 14:27 发表


这样当然是最好了，但是现实当中，至少就我个人而言，所维护的代码70%以上都是别人写的，或者是写的时候没有想到这些问题。等到意识到问题的时候，起码时间上已经不允许再做一个内存管理模块了，只能去通过 ...

你确定你碰到了内存碎片问题？
或者说，确实因为内存碎片导致你的程序变慢甚至系统变慢？