最终,我成功解决了这个问题,很高兴能分享我的发现。根据我的经验,评估程序内存消耗的最佳工具是来自Valgrind的Massif 工具。它可以让您对堆空间使用进行剖析并提供详细分析。
若要对应用程序的堆进行剖析,请运行valgrind --tool=massif prog
,这将为您提供关于典型的内存分配函数(如malloc
和相关函数)的基本访问权限。但是,为了深入挖掘,我激活了选项--pages-as-heap=yes
,它会报告有关底层系统调用的信息。以下是我的剖析会话中的一个示例:
67 1,284,382,720 978,575,360 978,575,360 0 0
100.00% (978,575,360B) (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc.
->87.28% (854,118,400B) 0x8282419: mmap (syscall-template.S:82)
| ->84.80% (829,849,600B) 0x821DF7D: _int_malloc (malloc.c:3226)
| | ->84.36% (825,507,840B) 0x821E49F: _int_memalign (malloc.c:5492)
| | | ->84.36% (825,507,840B) 0x8220591: memalign (malloc.c:3880)
| | | ->84.36% (825,507,840B) 0x82217A7: posix_memalign (malloc.c:6315)
| | | ->83.37% (815,792,128B) 0x4C74F9B: std::_Rb_tree_node<std::pair<std::string const, unsigned int> >* std::_Rb_tree<std::string, std::pair<std::string const, unsigned int>, std::_Select1st<std::pair<std::string const, unsigned int> >, std::less<std::string>, StrategizedAllocator<std::pair<std::string const, unsigned int>, MemalignStrategy<4096> > >::_M_create_node<std::pair<std::string, unsigned int> >(std::pair<std::string, unsigned int>&&) (MemalignStrategy.h:13)
| | | | ->83.37% (815,792,128B) 0x4C7529F: OrderIndifferentDictionary<std::string, MemalignStrategy<4096>, StrategizedAllocator>::addValue(std::string) (stl_tree.h:961)
| | | | ->83.37% (815,792,128B) 0x5458DC9: var_to_string(char***, unsigned long, unsigned long, AbstractTable*) (AbstractTable.h:341)
| | | | ->83.37% (815,792,128B) 0x545A466: MySQLInput::load(std::shared_ptr<AbstractTable>, std::vector<std::vector<ColumnMetadata*, std::allocator<ColumnMetadata*> >*, std::allocator<std::vector<ColumnMetadata*, std::allocator<ColumnMetadata*> >*> > const*, Loader::params const&) (MySQLLoader.cpp:161)
| | | | ->83.37% (815,792,128B) 0x54628F2: Loader::load(Loader::params const&) (Loader.cpp:133)
| | | | ->83.37% (815,792,128B) 0x4F6B487: MySQLTableLoad::executePlanOperation() (MySQLTableLoad.cpp:60)
| | | | ->83.37% (815,792,128B) 0x4F8F8F1: _PlanOperation::execute_throws() (PlanOperation.cpp:221)
| | | | ->83.37% (815,792,128B) 0x4F92B08: _PlanOperation::execute() (PlanOperation.cpp:262)
| | | | ->83.37% (815,792,128B) 0x4F92F00: _PlanOperation::operator()() (PlanOperation.cpp:204)
| | | | ->83.37% (815,792,128B) 0x656F9B0: TaskQueue::executeTask() (TaskQueue.cpp:88)
| | | | ->83.37% (815,792,128B) 0x7A70AD6: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
| | | | ->83.37% (815,792,128B) 0x6BAEEFA: start_thread (pthread_create.c:304)
| | | | ->83.37% (815,792,128B) 0x8285F4B: clone (clone.S:112)
| | | |
| | | ->00.99% (9,715,712B) in 1+ places, all below ms_print's threshold (01.00%)
| | |
| | ->00.44% (4,341,760B) in 1+ places, all below ms_print's threshold (01.00%)
正如您所看到的,我大约85%的内存分配来自于单个分支,现在问题是为什么内存消耗如此之高,如果原始堆分析显示正常消耗。如果您查看示例,您将会了解原因。为了分配,我使用了posix_memalign
来确保分配发生在有用的边界上。然后将该分配器从外部类传递给内部成员变量(在本例中为映射)以用于堆分配。然而,我选择的边界太大了 - 4096 - 在我的情况下。这意味着,您将使用posix_memalign
分配4b,但系统将为您分配整个页面以正确对齐它。如果您现在分配许多小值,则会产生大量未使用的内存。这些内存不会被常规堆分析工具报告,因为您只分配了其中一部分内存,但系统分配例程将分配更多并隐藏其余部分。
为了解决这个问题,我切换到了更小的边界,从而能够显著减少内存开销。
作为我花费在Massif和其他工具前的时间的结论,我只能建议使用这个工具进行深度分析,因为它可以让您非常好地了解发生了什么,并轻松跟踪错误。对于使用posix_memalign
的情况则略有不同。有些情况下确实需要使用它,但对于大多数情况,使用普通的malloc
就可以了。