Linux 内存管理-伙伴系统内存分配异常

gaojl0728

回复 9# humjb_1983


    没机会了， 这种问题出了之后全公司都上不去网， 客户早重启了，而且这种问题基本上很难重现，属于N年重现一回的那种，现在只是事后分析，也就只能看看log

gaojl0728

回复 7# 镇水铁牛


    不用测啊，看内存的分布就知道分配8K连续内存会失败。

gaojl0728

回复 8# chenyu105


    出问题的linux系统主要就是跑了一个HTTP代理服务器，要说场景也就是并发压力或大或小的问题，很难说具体什么原因导致的碎片，而且不能确定真的就是碎片，

就算真的全是碎片， 因为DMA32区的总大小才4120800KB, 4K的块总大小是233067*4kB=932268KB， 相当于DMA32区中23%的物理内存都是碎片，这也说明伙伴系统在某种极端情况下不能很好地控制碎片量， 其实这也算是bug吧.

对于在原子上下文导致的分配内存失败，因为不能睡眠，swap也派不上用场呢吧， 不过总体来说用上swap肯定能节省一部分物理内存，对系统压力来说有好处。
echo 3 > /proc/sys/vm/drop_cache 应该是可以缓解问题的，

gaojl0728

回复 3# super皮波


        4K的页要想合并成8K, 只有一个机会，那就是在释放下一个4K页的时候， 但是在释放4K页的时候有个问题就是还有个CPU高速缓存（per_cpu_pages），CPU高速缓存会优先缓存4K的页，不把高速缓存填满是不会释放4K页的也就没有机会合并，从dump的信息看DMA32高速缓存的最大容量是186，但是使用量却位0，说明当时内核也在快速的分配4K页，导致高速缓存被拿空了， 也就是说当时内核在同时快速的分配4K和8K的页面，8K虽然用完了但是因为4K的高速缓存一直空就一直没有机会合并4K页，
这可能是导致碎片的的一个原因吧。

从这一点来看的话， 其实内核应该优先合并4K的页，如果4K的页不能合并然后才放到高速缓存， 这样实现可能更加合理一点，这样能导致产生更少的碎片。

mnipxh

内存碎片是很容易产生的。比如下面的代码就让伙伴系统无能为力。
不知道你的http代理服务器用的mmap多不多。

int main(void)
{
        int i;
        char *array[65536];
        for (i = 0; i < 65536; i++) {
                array[i] = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
                if (array[i] == MAP_FAILED) perror("mmap"), exit(1);
                array[i][0] = 3;
        }
        for (i = 0; i < 65536; i += 2) {
                if (munmap(array[i], 4096)) perror("munmap"), exit(1);
        }
        pause();
        return 0;
}

super皮波

回复 14# gaojl0728

楼主把BUG都列出来吧，别一个一个来


   

humjb_1983

gaojl0728 发表于 2014-08-21 10:18
回复 9# humjb_1983

呵呵，那说明出现的概率也不高嘛，伙伴系统能应付大部分情况，看似还是可以的，呵呵。。。

super皮波

回复 17# humjb_1983
你对14楼的观点怎么看？


   

gaojl0728

回复 16# super皮波


    整理bug是个体力活，得找到以前搜集的数据， 有些数据时间长都找不到了， 找到数据之后还得看看代码做个大概的分析
最近忙着看面试题，你懂得，空闲时间更少了， 等我有空再发几个，

humjb_1983

humjb_1983 发表于 2014-08-21 13:54
呵呵，那说明出现的概率也不高嘛，伙伴系统能应付大部分情况，看似还是可以的，呵呵。。。

放到高速缓存中应该也是从效率考虑，如果先合并了，对效率也是一中伤害~，难以两全呀。具体算法倒是没有研究过。。。。