Analyzing MySQL Memory Usage with tcmalloc and pprof

The article begins by questioning why MySQL memory usage reported by the operating system often exceeds the figures gathered by performance_schema , and proposes an experiment to identify memory allocations that performance_schema does not capture.

First, the Google perftools package (tcmalloc) is installed, providing a custom memory allocator and heap‑dump capability. After installation, the relevant library files are verified.

A MySQL instance is initialized, its startup parameters are recorded, and the server is stopped. Before restarting MySQL, two environment variables are added to the launch command: LD_PRELOAD (pointing to the tcmalloc library) and HEAPPROFILE (specifying the output path for heap files).

When MySQL starts, two heap files appear in the log. Additional load is generated on the database using a familiar “doubling” method, which creates more heap files as the workload increases.

To analyze these heap dumps, the Go programming language is installed (requiring a proxy for download), followed by the installation of the pprof tool. The generated heap files are then processed with pprof , which produces an SVG visualization of memory allocation flows.

The SVG is opened in Chrome, where the diagram shows numerous allocation paths. Three major aggregation points are highlighted: one that performance_schema can trace (pfs_malloc) and two that it cannot. A zoomed‑in view of the diagram reveals that about 16 384.53 kB of memory is allocated by the function log_allocate_buffer via ut_allocator , a path not tracked by performance_schema.

Further inspection of the MySQL source confirms that log_allocate_buffer allocates memory based on the log_buffer_size configuration, matching the observed allocation size in the graph.

In summary, the experiment shows that using tcmalloc’s heap‑dump feature together with pprof provides a clear, low‑overhead way to visualize MySQL’s memory allocation, identify code paths responsible for large allocations, and discover memory usage that performance_schema misses, making it suitable for production‑level diagnostics.