01The discrepancy

A 62 GB host, 53.7 GB resident for a single mysqld, and an InnoDB buffer pool of roughly 33 GB. Nothing in the configuration accounted for the difference, and the gap left the host one workload spike from the OOM killer.

02MySQL says it's clean

Each of the usual suspects was tested against measurements rather than assumed. Temporary tables held kilobytes. Theoretical per-connection buffers across the whole connection limit came to well under a gigabyte. And MySQL's own instrumentation showed allocation and release in balance:

SUM_ALLOC   97.6 GB
SUM_FREE    97.6 GB
CURRENT     81 MB

MySQL was freeing the allocations. The allocator was retaining the memory instead of returning it efficiently to the OS.

03Below the engine

Conventional MySQL diagnostics could not explain the missing memory, so the investigation moved below the database engine into Linux process memory. Of the 53.7 GB resident, 46.1 GB was anonymous and around 32 GB was backed by huge pages — the buffer pool behaving correctly. More than 1,100 anonymous mappings, RSS still climbing during observation, and clean MySQL accounting pointed at allocator behaviour.

04Root cause

glibc allocator fragmentation, amplified by Transparent Huge Pages set to always. Under sustained churn MySQL frees correctly, but the allocator holds the fragmented memory rather than returning it to the kernel, and THP makes that reclaim behaviour worse.

The leak wasn't in MySQL. The missing memory was sitting between the database engine and the operating system.

05Remediation & validation

Both changes targeted the allocator layer rather than the database configuration, and both were reversible: disable Transparent Huge Pages, then move MySQL onto jemalloc with decay tuned to release dirty pages on a fixed interval. It shipped with success criteria rather than a shrug — track RSS after deployment and compare MySQL-accounted memory against OS resident memory, with the two expected to land within roughly 15% of each other.