内存碎片分析器
有没有好的内存碎片分析器？ （linux gcc 版本会很好）。 Valgrind 无法分析这一点，因为它使用自定义的 malloc/free 函数。
谢谢， 安德鲁
Are there any good memory fragmentation profilers? (linux gcc version would be nice). Valgrind cannot analyze this because it uses custom malloc/free functions.
Thanks,
Andrew
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我将从 mtrace 开始。当您进行跟踪时，glibc 会附带一个 perl 脚本 mtrace(1) 来查找泄漏。然而，跟踪格式很容易理解，因此应该直接将其处理为碎片分析。
I would start with mtrace. When you have a trace, glibc comes with a perl script mtrace(1) which finds leaks. However, the trace format is easy to understand, so it should be straight-forward process this into fragmentation analysis.
恐怕答案是 Valgrind。
您可以告诉 Valgrind 哪些函数用于进行分配以及如何使用 valgrind 代码扩展来执行分配（因此您需要修改并重新编译您的应用程序，但如果您不进行调试，则更改会编译为 noops），详细信息位于Valgrind 手册 内存池：使用自定义分配器 。
完成此操作后，您将拥有两个工具可以帮助您诊断堆使用情况：massif 和 DHAT（快速提醒，Valgrind 是一套工具，它只运行我们都知道的工具，并且爱，Memcheck，默认）。
Massif ”是一个堆分析器。它测量程序使用了多少堆内存。这包括有用的空间以及为簿记和对齐目的分配的额外字节，它还可以测量程序堆栈的大小，尽管默认情况下它不会这样做。”
它可以创建“图表”，因此它是图形化的：
19.63^ ### | # | # :: | # : ::: | :::::::::# : : :: | : # : : : :: | : # : : : : ::: | : # : : : : : :: | ::::::::::: # : : : : : : ::: | : : # : : : : : : : :: | ::::: : # : : : : : : : : :: | @@@: : : # : : : : : : : : : @ | ::@ : : : # : : : : : : : : : @ | :::: @ : : : # : : : : : : : : : @ | ::: : @ : : : # : : : : : : : : : @ | ::: : : @ : : : # : : : : : : : : : @ | :::: : : : @ : : : # : : : : : : : : : @ | ::: : : : : @ : : : # : : : : : : : : : @ | :::: : : : : : @ : : : # : : : : : : : : : @ | ::: : : : : : : @ : : : # : : : : : : : : : @ 0 +----------------------------------------------------------------------->KB 0 29.48 Number of snapshots: 25 Detailed snapshots: [9, 14 (peak), 24]此外，还有一个 Massif Visualizer 可以生成非常漂亮的图表。
DHAT 允许您诊断应用程序如何准确地使用其堆，哪些部分很短live，它们在整个程序的生命周期中保留，但仅在开始时使用等。不幸的是，它没有任何漂亮的图表或图形工具，输出是纯文本。值得庆幸的是，您可以告诉它您想要获取多少数据以及如何对其进行排序，这样它就不会像听起来那么糟糕。
I'm afraid the answer is Valgrind.
You can tell Valgrind which functions are used to make allocations and how it does it using valgrind extensions to code (so you need to modify and recompile your application, but the changes compile to noops if you're not debugging), the details are in Valgrind manual Memory pools: working with custom allocators.
Once you've done this, you have two tools that allow you to diagnose your heap usage: massif and DHAT (quick reminder, Valgrind is a set of tools, it just runs the one we all know and love, Memcheck, as default).
Massif "is a heap profiler. It measures how much heap memory your program uses. This includes both the useful space, and the extra bytes allocated for book-keeping and alignment purposes. It can also measure the size of your program's stack(s), although it does not do so by default."
It can create "graphs", so it is kind of graphical:
19.63^ ### | # | # :: | # : ::: | :::::::::# : : :: | : # : : : :: | : # : : : : ::: | : # : : : : : :: | ::::::::::: # : : : : : : ::: | : : # : : : : : : : :: | ::::: : # : : : : : : : : :: | @@@: : : # : : : : : : : : : @ | ::@ : : : # : : : : : : : : : @ | :::: @ : : : # : : : : : : : : : @ | ::: : @ : : : # : : : : : : : : : @ | ::: : : @ : : : # : : : : : : : : : @ | :::: : : : @ : : : # : : : : : : : : : @ | ::: : : : : @ : : : # : : : : : : : : : @ | :::: : : : : : @ : : : # : : : : : : : : : @ | ::: : : : : : : @ : : : # : : : : : : : : : @ 0 +----------------------------------------------------------------------->KB 0 29.48 Number of snapshots: 25 Detailed snapshots: [9, 14 (peak), 24]What's more, there's a Massif Visualizer that is produces really pretty graphs.
DHAT allows you to diagnose how exactly the application uses its heap, which parts are short lived, which are kept through whole program's life, but used only in the beginning, etc. Unfortunately it doesn't have any nice graphs or graphical tools that go with it, the output is pure text. Thankfully you can tell it how much data you want to get and how to sort it so it's not as bad as it sounds.
我很难理解您可能找到的任何工具如何理解自定义内存管理的段数据结构。您也许能够获得繁忙的发行版（挂钩到 malloc/free），但免费发行版（本质上是碎片）似乎悬而未决。
那么为什么不将繁忙/空闲统计信息/直方图添加到您的自定义内存管理器中呢？如果 bin 按与 log2(size) 成比例的内容进行索引，则其 O(1) 可以保留这些统计信息，因为当您拆分和合并时，您知道大小，并且可以使用与 log2(size) 成比例的索引通过直接查找来找到 bin，
例如直方图 bin 间隔
[2^n,2^(n+1) ) ...
（例如，如果您想要更精细的 bin，请使用对数基数平方根 2(size)
可以在 x86 上使用 4 个整数指令进行计算 [位扫描、比较、设置、添加]）
另一组要使用的合理 bin 大小是以下开区间
[2^n, 2^n+2^(n-1) ),[2^n+2^(n-1),2^(n+1) )...
再次轻松计算[位扫描、移位和相加])
I have trouble understanding how any tool you might find would understand the segment data structures of your custom memory management. You might be able to get the busy distribution(hooking into malloc/free) but the free distribution (which essentially is the fragmentation) seems up in the air.
So why not add busy/free statistics/histograms to your custom memory manager. If bins are indexed by something proportional to log2(size) its O(1) to keep these statistics as when you split and coalesce you know the sizes and you can find the bin by direct lookup using an index proportional to log2(size)
eg histogram bin intervals
[2^n,2^(n+1) ) ...
(eg if you want finer bins use log base square root 2(size)
which can be calculated with 4 integer instructions on x86 [bit scan, compare, set, add])
another set of reasonable bin sizes to use are the following open intervals
[2^n, 2^n+2^(n-1) ),[2^n+2^(n-1),2^(n+1) )...
again easily calculable [bit scan, shift, and, add])
nedmalloc 是一个非常好的自定义分配器，附带源代码，经过优化以避免碎片。
我将其插入，并开始查看其内部日志记录以获取碎片统计信息。
nedmalloc is a very good custom allocator, comes with source, optimized to avoid fragmentation.
I would plug that in, and start looking at its internal logging for fragmentation statistics.