Understanding MySQL OOM Killer, Memory Planning, and Detecting Memory Leaks with Valgrind

Introduction: The author, an intern engineer, encountered a case where a MySQL instance's mysqld process memory continuously grew until the Linux OOM killer terminated it, prompting an investigation of possible causes.

Explanation of OOM Killer: The OOM killer selects a process to kill based on a "badness" score that favors processes using large memory, having many child processes, and not being critical system processes. MySQL, with its large memory allocation, often becomes a target.

MySQL memory planning: The article discusses the importance of configuring InnoDB buffer pool size (commonly 50‑80% of physical RAM) and ensuring the total of buffer pool and per‑connection memory does not exceed physical memory. An example shows a mis‑configured instance allocating 76 GB buffer pool with 3000 connections, potentially using 545 GB, far beyond the 97 GB server memory, leading to OOM.

Memory leak overview: Defines memory leaks, their hidden and cumulative nature, and why they are hard to detect.

Valgrind tools: Introduces Valgrind as a framework with tools such as Memcheck, Cachegrind, Callgrind, Helgrind, DRD, Massif, DHAT, SGcheck, BBV. Emphasizes Memcheck for detecting memory errors, including leaks.

Using Valgrind: Example command to run Memcheck on a program:

valgrind --tool=memcheck ./a.out

Testing MySQL with Valgrind: Steps to start mysqld under Memcheck, generate load with sysbench, and examine the leak summary. Sample command:

valgrind --tool=memcheck --leak-check=full --show-reachable=yes --log-file=/tmp/valgrind-mysql.log /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --user=root

Sample leak summary output (truncated):

==29326== LEAK SUMMARY:
==29326==    definitely lost: 0 bytes in 0 blocks
==29326==    indirectly lost: 0 bytes in 0 blocks
==29326==    possibly lost: 549,072 bytes in 1,727 blocks
==29326==    still reachable: 446,492,944 bytes in 54 blocks
==29326== ERROR SUMMARY: 339 errors from 339 contexts

Another test disabling performance_schema showed no leaks, suggesting that performance_schema may contribute to memory consumption and potential leaks.

Final recommendations: Properly size InnoDB buffer pool, adjust oom_score_adj to lower MySQL's OOM priority, monitor memory and set alerts, and consider disabling or limiting performance_schema when not needed.