我一直在32位linux上使用boost线程已经有一段时间了,我对它们迄今为止的表现非常满意。最近该项目被转移到64位平台,我们看到内存使用量大幅增加(从大约2.5gb到16-17gb)。我已经完成了分析,发现增强线程是巨大分配的来源。每个线程的分配大约是32位上的10倍。
我使用valgrind的massif进行了分析,并在单独的测试应用程序中仅使用boost线程确认了该问题。我也试过使用std :: threads,这些没有出现大的内存分配问题。
我想知道是否有其他人看过这种行为并知道问题是什么?感谢。
答案 0 :(得分:3)
没问题。这是虚拟内存,每个64位进程可以在每个现代操作系统上分配数TB的虚拟内存。它基本上是免费的,没有理由关心它的使用量。
它基本上只是线程堆栈的保留空间。如果需要,可以通过更改默认堆栈大小来减少它。但是绝对没有理由。
答案 1 :(得分:3)
使用pthread_attr_getstacksize查看。使用boost :: thread :: attributes进行更改(pthread_attr_setstacksize)。
boost.thread的gdb示例
0 0x000000000040ffe0 in boost::detail::get_once_per_thread_epoch() ()
1 0x0000000000407c12 in void boost::call_once<void (*)()>(boost::once_flag&, void (*)()) [clone .constprop.120] ()
2 0x00000000004082cf in thread_proxy ()
3 0x000000000041120a in start_thread (arg=0x7ffff7ffd700) at pthread_create.c:308
4 0x00000000004c5cf9 in clone ()
5 0x0000000000000000 in ?? ()
您将在get_once_per_thread_epoch( boost_1_50_0 / libs / thread / src / pthread / once.cpp )中发现data=malloc(sizeof(boost::uintmax_t));
继续
1 0x000000000041a0d3 in new_heap ()
2 0x000000000041b045 in arena_get2.isra.5.part.6 ()
3 0x000000000041ed13 in malloc ()
4 0x0000000000401b1a in test () at pthread_malloc_8byte.cc:9
5 0x0000000000402d3a in start_thread (arg=0x7ffff7ffd700) at pthread_create.c:308
6 0x00000000004413d9 in clone ()
7 0x0000000000000000 in ?? ()
在new_heap函数( glibc-2.15 \ malloc \ arena.c )中,它将为64位操作系统中的每个线程预先映射64M内存。换句话说,每个线程将使用 64M + 8M(默认线程堆栈)= 72M 。
glibc-2.15\ChangeLog.17
2009-03-13 Ulrich Drepper <drepper@redhat.com>
* malloc/malloc.c: Implement PER_THREAD and ATOMIC_FASTBINS features.
* malloc/arena.c: Likewise.
* malloc/hooks.c: Likewise.