了解 glibc malloc 修剪
Understanding glibc malloc trimming
我目前正在处理的一些程序消耗的内存比我认为的要多。所以我想了解 glibc malloc 修剪是如何工作的。我写了以下测试:
#include <malloc.h>
#include <unistd.h>
#define NUM_CHUNKS 1000000
#define CHUNCK_SIZE 100
int main()
{
// disable fast bins
mallopt(M_MXFAST, 0);
void** array = (void**)malloc(sizeof(void*) * NUM_CHUNKS);
// allocating memory
for(unsigned int i = 0; i < NUM_CHUNKS; i++)
{
array[i] = malloc(CHUNCK_SIZE);
}
// releasing memory ALMOST all memory
for(unsigned int i = 0; i < NUM_CHUNKS - 1 ; i++)
{
free(array[i]);
}
// when enabled memory consumption reduces
//int ret = malloc_trim(0);
//printf("ret=%d\n", ret);
malloc_stats();
sleep(100000);
}
测试输出(不调用malloc_trim):
Arena 0:
system bytes = 112054272
in use bytes = 112
Total (incl. mmap):
system bytes = 120057856
in use bytes = 8003696
max mmap regions = 1
max mmap bytes = 8003584
尽管几乎所有内存都已释放,但此测试代码消耗的常驻内存比预期的要多得多:
[root@node0-b3]# ps aux | grep test
root 14662 1.8 0.4 129736 **118024** pts/10 S 20:19 0:00 ./test
处理映射:
0245e000-08f3b000 rw-p 00000000 00:00 0 [heap]
Size: 109428 kB
Rss: 109376 kB
Pss: 109376 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 109376 kB
Referenced: 109376 kB
Anonymous: 109376 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr mr mw me ac
7f1c60720000-7f1c60ec2000 rw-p 00000000 00:00 0
Size: 7816 kB
Rss: 7816 kB
Pss: 7816 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 7816 kB
Referenced: 7816 kB
Anonymous: 7816 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
当我启用对 malloc_trim 的调用时,测试的输出几乎保持不变:
ret=1
Arena 0:
system bytes = 112001024
in use bytes = 112
Total (incl. mmap):
system bytes = 120004608
in use bytes = 8003696
max mmap regions = 1
max mmap bytes = 8003584
然而,RSS 明显减少:
[root@node0-b3]# ps aux | grep test
root 15733 0.6 0.0 129688 **8804** pts/10 S 20:20 0:00 ./test
处理 smap(在 malloc_trim 之后):
01698000-08168000 rw-p 00000000 00:00 0 [heap]
Size: 109376 kB
Rss: 8 kB
Pss: 8 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 8 kB
Referenced: 8 kB
Anonymous: 8 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr mr mw me ac
7f508122a000-7f50819cc000 rw-p 00000000 00:00 0
Size: 7816 kB
Rss: 7816 kB
Pss: 7816 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 7816 kB
Referenced: 7816 kB
Anonymous: 7816 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
调用 malloc_trim 后,堆变小了。我假设 8MB mmap 段仍然可用,因为最后一块内存没有被释放。
为什么 malloc 不自动执行堆修剪?
有没有办法配置 malloc 以便自动完成修剪(当它可以节省那么多内存时)?
我使用的是 glibc 2.17 版。
很大程度上出于历史原因,小分配的内存来自由 brk
system call. This is a very old system call — at least as old as Version 6 Unix 管理的池 — 它唯一能做的就是 更改大小 "arena" 在内存中的位置是固定的。这意味着,brk
池不能缩小超过仍然分配的块。
您的程序分配了 N 个内存块,然后释放了其中的 N-1 个。它没有释放的一个块是位于 最高 地址的那个。这是 brk
的最坏情况:即使 99.99% 的池未使用,大小也根本无法减少!如果您更改您的程序,使其未释放的块是 array[0]
而不是 array[NUM_CHUNKS-1]
,您应该会看到 RSS 和地址 space 在最终调用 [=15= 时缩小].
当您显式调用 malloc_trim
时,它会尝试使用 Linux 扩展 madvise(MADV_DONTNEED)
来解决此限制,这会释放物理 RAM,但不会释放地址 [=36] =](如您所见)。我不知道为什么这只会在显式调用 malloc_trim
.
时发生
顺便说一下,8MB 的 mmap 段是为您初始分配的 array
。
我目前正在处理的一些程序消耗的内存比我认为的要多。所以我想了解 glibc malloc 修剪是如何工作的。我写了以下测试:
#include <malloc.h>
#include <unistd.h>
#define NUM_CHUNKS 1000000
#define CHUNCK_SIZE 100
int main()
{
// disable fast bins
mallopt(M_MXFAST, 0);
void** array = (void**)malloc(sizeof(void*) * NUM_CHUNKS);
// allocating memory
for(unsigned int i = 0; i < NUM_CHUNKS; i++)
{
array[i] = malloc(CHUNCK_SIZE);
}
// releasing memory ALMOST all memory
for(unsigned int i = 0; i < NUM_CHUNKS - 1 ; i++)
{
free(array[i]);
}
// when enabled memory consumption reduces
//int ret = malloc_trim(0);
//printf("ret=%d\n", ret);
malloc_stats();
sleep(100000);
}
测试输出(不调用malloc_trim):
Arena 0:
system bytes = 112054272
in use bytes = 112
Total (incl. mmap):
system bytes = 120057856
in use bytes = 8003696
max mmap regions = 1
max mmap bytes = 8003584
尽管几乎所有内存都已释放,但此测试代码消耗的常驻内存比预期的要多得多:
[root@node0-b3]# ps aux | grep test
root 14662 1.8 0.4 129736 **118024** pts/10 S 20:19 0:00 ./test
处理映射:
0245e000-08f3b000 rw-p 00000000 00:00 0 [heap]
Size: 109428 kB
Rss: 109376 kB
Pss: 109376 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 109376 kB
Referenced: 109376 kB
Anonymous: 109376 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr mr mw me ac
7f1c60720000-7f1c60ec2000 rw-p 00000000 00:00 0
Size: 7816 kB
Rss: 7816 kB
Pss: 7816 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 7816 kB
Referenced: 7816 kB
Anonymous: 7816 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
当我启用对 malloc_trim 的调用时,测试的输出几乎保持不变:
ret=1
Arena 0:
system bytes = 112001024
in use bytes = 112
Total (incl. mmap):
system bytes = 120004608
in use bytes = 8003696
max mmap regions = 1
max mmap bytes = 8003584
然而,RSS 明显减少:
[root@node0-b3]# ps aux | grep test
root 15733 0.6 0.0 129688 **8804** pts/10 S 20:20 0:00 ./test
处理 smap(在 malloc_trim 之后):
01698000-08168000 rw-p 00000000 00:00 0 [heap]
Size: 109376 kB
Rss: 8 kB
Pss: 8 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 8 kB
Referenced: 8 kB
Anonymous: 8 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr mr mw me ac
7f508122a000-7f50819cc000 rw-p 00000000 00:00 0
Size: 7816 kB
Rss: 7816 kB
Pss: 7816 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 7816 kB
Referenced: 7816 kB
Anonymous: 7816 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
调用 malloc_trim 后,堆变小了。我假设 8MB mmap 段仍然可用,因为最后一块内存没有被释放。
为什么 malloc 不自动执行堆修剪? 有没有办法配置 malloc 以便自动完成修剪(当它可以节省那么多内存时)?
我使用的是 glibc 2.17 版。
很大程度上出于历史原因,小分配的内存来自由 brk
system call. This is a very old system call — at least as old as Version 6 Unix 管理的池 — 它唯一能做的就是 更改大小 "arena" 在内存中的位置是固定的。这意味着,brk
池不能缩小超过仍然分配的块。
您的程序分配了 N 个内存块,然后释放了其中的 N-1 个。它没有释放的一个块是位于 最高 地址的那个。这是 brk
的最坏情况:即使 99.99% 的池未使用,大小也根本无法减少!如果您更改您的程序,使其未释放的块是 array[0]
而不是 array[NUM_CHUNKS-1]
,您应该会看到 RSS 和地址 space 在最终调用 [=15= 时缩小].
当您显式调用 malloc_trim
时,它会尝试使用 Linux 扩展 madvise(MADV_DONTNEED)
来解决此限制,这会释放物理 RAM,但不会释放地址 [=36] =](如您所见)。我不知道为什么这只会在显式调用 malloc_trim
.
顺便说一下,8MB 的 mmap 段是为您初始分配的 array
。