Analyzing MySQL OOM During High-Concurrency Sysbench Load and the Role of vm.overcommit_memory

When performing a sysbench load test on MySQL with 100 concurrent threads, the server unexpectedly reports out‑of‑memory (OOM) errors despite having sufficient physical memory, prompting an investigation into the root cause.

# sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=BJDB-02 --mysql-port=3306 --mysql-user=root --mysql-password=*** --mysql-db=test --table-size=100000 --tables=5 --threads=100 --db-ps-mode=disable --auto_inc=off --report-interval=3 --max-requests=0 --time=360 --percentile=95 --skip_trx=off --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 --create_secondary=off run

The MySQL error log shows messages such as Out of memory (Needed 48944 bytes) and InnoDB assertion failures, indicating memory allocation failures.

Initial analysis checks the ulimit settings, confirming no restrictive limits are applied:

# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
... (other limits) ...
virtual memory          (kbytes, -v) unlimited

Memory usage is then examined with free -m and top, revealing ample free and available memory, no swap usage, and a relatively high virtual memory size for the MySQL process.

# free -m
              total        used        free      shared  buff/cache   available
Mem:          16047        1958        8956          8        5132       13920
Swap:          5119           0        5119

# top - 17:21:30 up 32 min,  4 users,  load average: 0.00, 0.04, 0.11
... (output truncated) ...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7654 root 20 0 13.7g 1.7g 14312 S 1.3 10.3 0:00.27 mysqld

Further inspection of /proc/meminfo highlights the CommitLimit and Committed_AS values, which are close to each other, suggesting the system is near its overcommit threshold.

# cat /proc/meminfo | grep Commit
CommitLimit:     13458992 kB
Committed_AS:    13244484 kB

The kernel parameter vm.overcommit_memory is found set to 2, enforcing a strict “never overcommit” policy. Changing this parameter to 0 (heuristic overcommit) resolves the OOM issue during the test.

# cat /etc/sysctl.conf |grep vm.overcommit_memory
vm.overcommit_memory=2

The article then explains the three possible values of vm.overcommit_memory:

0 – Heuristic overcommit (default): the kernel estimates free memory and may reject obviously large allocations.

1 – Always overcommit: the kernel assumes memory is always available until it actually runs out.

2 – Never overcommit: the kernel prevents any overcommit, limiting total commit to swap + vm.overcommit_ratio * RAM.

When set to 2, the effective commit limit is calculated as: CommitLimit = Physical RAM * vm.overcommit_ratio + Swap (default vm.overcommit_ratio is 50%). In the test environment with ~16 GB RAM and ~5 GB swap, the limit is about 13 GB, close to the observed Committed_AS value, making MySQL prone to OOM.

The article concludes that adjusting vm.overcommit_memory to 0 (or tuning vm.overcommit_ratio) prevents the OOM situation, and mentions related parameters admin_reserve_kbytes and user_reserve_kbytes for further tuning.

References to kernel documentation are provided for deeper reading.