我在32位linux上使用boost线程已经有一段时间了,到目前为止我对它们的性能非常满意。最近,这个项目被转移到了一个64位的平台上,我们看到内存使用量大幅增加(从2.5gb增加到16-17gb)。我做了分析,发现boost线程是巨大分配的来源。每个线程都在分配它在32位上所做的大约10倍的工作。
我使用valgrind的massif进行了剖析,并且仅在单独的测试应用程序中使用boost线程确认了这个问题。我还尝试使用std::线程,而这些线程并没有出现大内存分配问题。
我想知道是否有其他人见过这种行为,知道问题出在哪里?谢谢。
发布于 2012-08-27 01:25:12
没什么问题。这是虚拟内存,每个64位进程都可以在每个现代操作系统上分配兆字节的虚拟内存。它基本上是免费的,没有理由去关心它使用了多少。
它基本上只是为线程堆栈预留空间。如果需要,可以通过更改默认堆栈大小来减少它。但绝对没有理由这么做。
发布于 2013-05-06 12:12:28
1.每线程的堆栈大小
使用pthread_attr_getstacksize查看。使用boost::线程::attributes to change (pthread_attr_setstacksize)。
2. glibc's malloc中每线程的预mmap
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 ?? () 您将在boost_1_50_0/libs/thread/src/pthread/once.cpp中发现data=malloc(sizeof(boost::uintmax_t)); in get_once_per_thread_epoch
继续
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 ?? () 在(glibc-2.15\malloc\arena.c),函数new_heap中,它将为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. https://stackoverflow.com/questions/12135226
复制相似问题