请求解析malloc_info输出各字段含义（基于EGLIBC 2.19）

I get it, dealing with malloc_info(3)'s undocumented XML output can be frustrating when you're trying to track down memory fragmentation—especially since the docs warn the format might change but give zero details. Let's break down every part of that output snippet you shared, tailored to your Ubuntu 14.04 (EGLIBC 2.19) environment (which behaves nearly identically to standard glibc for malloc).

Overall Structure #

The root element <malloc version="1"> tells you you're looking at version 1 of the malloc info format, tied to the glibc/EGLIBC malloc implementation. Inside this, you'll find multiple <heap nr="N"> elements (each representing a separate memory heap managed by malloc, numbered starting at 0), followed by global <total> elements that aggregate data across all heaps.

Per-Heap Details (<heap nr="N">) #

Each heap element contains metadata about how that specific heap is being used:

<sizes>: Memory Block Size Breakdown

This section tracks allocated and free memory blocks by their size ranges:

• <size from="X" to="Y" total="Z" count="C"/>: This means there are C memory blocks, each sized between X and Y bytes (often X equals Y, indicating fixed-size blocks). The total combined size of these blocks is Z bytes. These are blocks that fit into malloc's organized "bins" (small, large, etc.).
• <unsorted from="A" to="B" total="D" count="E"/>: This represents E uncategorized blocks, with sizes ranging from A to B bytes and a total size of D bytes. Unsorted blocks are typically small, fragmented free blocks that haven't been merged into standard bins yet—this is a key indicator of potential memory fragmentation.

<total type="fast" count="..." size="..."/>

The fast type refers to fast bins, a malloc optimization for small memory blocks (usually ≤64 bytes in EGLIBC 2.19). These blocks aren't immediately merged when freed, which speeds up allocation/deallocation but can contribute to minor fragmentation. This line counts the total number of fast bin blocks and their combined size in the heap.

<total type="rest" count="..." size="..."/>

rest covers all other memory blocks in the heap: this includes blocks from small bins, large bins, the unsorted bin, and allocated blocks. The count is the total number of these blocks, and size is their combined byte count.

<system type="current" size="..."/>

This shows the total amount of memory the heap has currently requested from the operating system (via sbrk or mmap). It's the raw memory the kernel has given to this heap.

<system type="max" size="..."/>

This is the peak amount of memory the heap has ever requested from the OS. It helps you track how much the heap has grown over time.

<aspace type="total" size="..."/>

aspace total is the total size of the virtual address space reserved for this heap. This includes both memory that's been mapped to physical RAM and unused address space within the heap's range.

<aspace type="mprotect" size="..."/>

aspace mprotect is the portion of the heap's address space that's been marked as accessible (via mprotect). This excludes any address space in the heap that's been marked as inaccessible (e.g., guard pages or unused regions).

Global Aggregate <total> Elements #

At the end of the XML, the top-level <total> elements sum up data across all heaps in the process:

• fast: Total count and size of fast bin blocks across all heaps
• rest: Total count and size of all non-fast-bin blocks across all heaps
• system current: Total memory currently requested from the OS by all heaps (this is a close proxy for the process's overall memory footprint from the kernel's perspective)
• system max: Peak total memory requested from the OS by all heaps
• aspace total: Total virtual address space reserved for all heaps
• aspace mprotect: Total accessible address space across all heaps

Key Tips for Debugging Memory Fragmentation #

Using this data, you can spot fragmentation red flags:

• A large <unsorted> entry (high count and size) means you have many small, unmerged free blocks that can't be easily reused for new allocations.
• If system current is significantly larger than the rest size, it means a lot of the memory the heap requested from the OS is sitting idle (free but not returned to the kernel)—this is a sign of heap fragmentation preventing memory release.
• A high number of distinct <size> entries (especially with small, varying ranges) indicates your application is allocating many different small block sizes, which increases the chance of fragmentation.

内容的提问来源于stack exchange，提问作者Roger Lipscombe