Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsStop recurring mysqld kills by finding which memory boundary is being exhausted, then making MySQL’s peak usage fit inside that boundary. The boundary may be the whole host, a container or cgroup limit, or a systemd-oomd policy. Start by confirming the killer, measure peak rather than idle memory, and set a budget that covers the InnoDB buffer pool, global caches, per-connection allocations, temporary tables, the operating system and every service sharing the machine. Reducing innodb_buffer_pool_size is often necessary, but high max_connections or oversized per-thread buffers can still trigger an OOM event.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What “out of memory” means for MySQL
Linux can terminate MySQL for three different reasons that look similar in an alert:
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Host-wide OOM: the machine cannot satisfy another allocation after accounting for RAM and available swap.
- cgroup or container OOM: the service reaches its assigned memory limit even though the host still has free RAM. The kernel enforces the cgroup’s
memory.max; host capacity does not override it. - systemd-oomd action: a userspace service observes sustained memory pressure or swap pressure in a cgroup and kills an eligible unit before the kernel’s OOM handler runs.
The fix depends on the scope. A smaller buffer pool helps all three cases, but changing an OOM score or adding host RAM will not solve a container limit, and increasing a container limit will not help if the host itself is exhausted.
1. Confirm which process killed MySQL
Check kernel records
Run these commands as soon as possible after the incident:
#1 Best Overall
journalctl -k --since "-2 hours" | grep -Ei 'oom|out of memory|killed process|memory cgroup'
dmesg -T | grep -Ei 'oom|out of memory|killed process|memory cgroup'dmesg may be unavailable to unprivileged users or on systems that route all kernel messages to the journal. Look for the killed PID, the process name (usually mysqld), total and free memory, swap activity, and wording such as “Memory cgroup out of memory.” A cgroup message points to a service or container limit rather than a shortage of the entire host.
Check MySQL’s error log
Find the configured error-log path and inspect the timestamp surrounding the termination:
mysql -NBe "SHOW VARIABLES LIKE 'log_error';"
# Then inspect the path returned by the command, for example:
sudo grep -Ei 'shutdown|signal|killed|out of memory' /path/to/mysql-error.logThe error log may show an abrupt exit without identifying the killer. Treat the kernel or service-manager journal as authoritative for victim selection.
Record a before-and-after snapshot
Capture the killed PID if it is still present in the logs, its resident set size (RSS), swap usage, and the number of active connections. An idle RSS reading after a restart is not a safe sizing baseline; temporary peaks are what trigger the kill.
2. Identify the memory scope
Host limits
Check physical memory, swap and current pressure:
free -h
swapon --show
cat /proc/pressure/memory
ps -o pid,rss,vsz,cmd -C mysqldLinux documentation notes that the amount of “allowed” memory depends on the context in which the OOM killer was called. A host can have apparently available RAM while a constrained service is already over its permitted limit.
Container or cgroup limits
For a cgroup-v2 service, inspect the effective limit and current usage from the unit’s cgroup. The exact path varies, so obtain it first:
systemctl show -p ControlGroup mysql.service
# Replace /sys/fs/cgroup/<path> with the path reported above:
cat /sys/fs/cgroup/<path>/memory.max
cat /sys/fs/cgroup/<path>/memory.current
cat /sys/fs/cgroup/<path>/memory.eventsmemory.max is the hard ceiling; max means no finite cgroup ceiling at that level. In memory.events, an increasing oom or oom_kill counter confirms cgroup pressure. In a container runtime, inspect the container’s memory limit and its parent cgroup as well. A host-level free -h result cannot prove that the container has headroom.
systemd service policy
Display limits and managed-OOM settings for the unit:
systemctl show mysql.service
-p MemoryMax -p MemoryHigh -p ManagedOOMSwap -p ManagedOOMMemoryPressure
systemctl cat mysql.service
systemctl status systemd-oomd
journalctl -u systemd-oomd --since "-2 hours"MemoryHigh applies reclaim and throttling pressure; MemoryMax is the hard limit. Drop-in files may set values that are not visible in the vendor unit alone. The systemd-oomd service uses cgroups-v2 and pressure-stall information (PSI) to monitor units and take corrective action before a kernel-space OOM. If its journal names the MySQL unit, do not attribute the event solely to the kernel.
3. Build a real MySQL memory inventory
Run the following query and save the result with your incident record:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →SHOW VARIABLES WHERE Variable_name IN (
'innodb_buffer_pool_size','key_buffer_size','max_connections',
'sort_buffer_size','read_buffer_size','read_rnd_buffer_size',
'join_buffer_size','tmp_table_size','max_heap_table_size',
'binlog_cache_size','binlog_stmt_cache_size',
'thread_stack','thread_cache_size','table_open_cache',
'performance_schema'
);Global allocations
innodb_buffer_pool_size is usually the largest reservation for an InnoDB workload. MyISAM indexes use key_buffer_size. Other global consumers include the table and definition caches, Performance Schema instrumentation, replication buffers, binary-log caches and memory held by client libraries. These allocations exist even when few queries are running.
Per-connection allocations
Sort, read, read-random and join buffers are allocated as sessions need them, not necessarily when the server starts. A large value multiplied by many concurrently executing sessions can produce a sudden peak. Thread stacks also matter: an Oracle-provided MySQL binary commonly uses a 256 KB stack, while a 2 MB stack is a frequent value in other builds. Check your actual thread_stack rather than assuming either figure.
Temporary tables and workload bursts
Queries that cannot remain in memory spill to disk; queries that fit within tmp_table_size and max_heap_table_size can consume RAM per session. The larger of the two settings is not a guaranteed reservation, but it defines how much an individual in-memory temporary table can grow. Reporting jobs, matchmaking searches or a game-launch event can create many such sessions simultaneously.
4. Calculate a safe memory budget
Oracle’s current MySQL Reference Manual gives 50%–75% of system memory as a typical starting range for innodb_buffer_pool_size. That is a starting point, not a promise of safety. A database sharing a game server, log collector, monitoring agent or cache may need considerably less.
Rank #3
MySQL’s illustrative startup estimate is:
innodb_buffer_pool_size
+ key_buffer_size
+ max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size)
+ max_connections * 2MBUse this as a lower-bound planning aid. Add expected temporary-table growth, read_rnd_buffer_size, join_buffer_size, thread stacks, Performance Schema, replication or binary-log overhead, filesystem cache and a safety reserve. The formula is not a peak-use guarantee because not every per-thread buffer is allocated by every session at once, but a configuration that fails this basic budget is already unsafe.
Worked planning example
Suppose a cgroup allows 8 GiB and other services require 1.5 GiB. Reserve another 1 GiB for the operating system, filesystem cache and burst headroom. MySQL then has about 5.5 GiB for its working set. A 4 GiB buffer pool leaves 1.5 GiB for connections, global structures and temporary growth. If max_connections is 500, even modest 1–2 MB per-session overhead can consume that remainder during a connection storm. Lowering the connection ceiling or placing a measured pool in front of MySQL may be safer than shrinking the buffer pool until query latency becomes unacceptable.
Measure peaks, not averages
Track RSS and cgroup usage at short intervals during the busiest workload, and record the highest concurrent connection count. Compare that peak with memory.current or host RSS. A low overnight reading only proves that the server is quiet; it does not establish a safe limit for a launch, tournament or scheduled analytics task.
5. Apply changes in the order that limits peak memory
Reduce the buffer pool conservatively
Set a value that leaves explicit room for the operating system, co-resident services and connection bursts. MySQL documents online resizing of the InnoDB buffer pool, so a resize can often be tested without a restart:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
SET GLOBAL innodb_buffer_pool_size = 4294967296;The value is in bytes; use your planned size and confirm the resulting value with SHOW VARIABLES LIKE 'innodb_buffer_pool_size';. Resize in measured steps, watch latency and dirty-page flushing, and persist the approved value in the server configuration so a restart does not restore an unsafe setting. Some related variables are not dynamic and require a controlled restart; verify each variable’s dynamic status before scheduling downtime.
Cap connections to real demand
Set max_connections to the measured concurrency requirement plus a small operational margin, not to an arbitrary four-digit number. An application connection pool can queue excess requests and smooth bursts. Lowering this setting can expose connection errors or queueing in the application, so coordinate the change with retry, timeout and pool settings.
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SET GLOBAL max_connections = 200;Persist the chosen value in the MySQL configuration. The dynamic change affects new connection attempts; existing sessions remain until they disconnect.
Rank #4
Right-size per-thread buffers
Reduce unusually large sort_buffer_size, read_buffer_size, read_rnd_buffer_size, join_buffer_size, tmp_table_size and max_heap_table_size before raising the buffer pool again. These settings trade memory for the possibility of fewer disk operations; reducing them may increase query latency or disk temporary tables. Change one group at a time and inspect slow queries rather than compensating for an inefficient query with a server-wide allocation.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchReview binary-log and replication settings
Binary-log caches and replication workers add memory beyond the simple buffer-pool calculation. Keep binlog_cache_size and related caches aligned with transaction sizes, and include worker concurrency in the peak budget. A replica that is safe when idle can exceed its cgroup limit while applying a backlog.
6. Fix container and systemd limits instead of fighting them
When the cgroup is too small
If memory.current approaches memory.max while the host has free RAM, choose one of two explicit fixes:
- Raise the service or container memory limit and verify that the host has capacity for the new worst case.
- Keep the limit and reduce MySQL’s total budget, including the buffer pool and connection-related peaks, until measured usage stays below it with headroom.
Raising a limit increases infrastructure consumption and can move the failure to the host or another tenant. Reducing MySQL’s budget may lower cache hit rates or throughput but is immediately reversible and usually easier to validate.
When systemd-oomd is selecting the unit
Inspect ManagedOOMSwap= and ManagedOOMMemoryPressure= in the unit and its drop-ins, then correlate the action with PSI and swap pressure in the systemd-oomd journal. Adjust policy only after the service fits its cgroup budget. Disabling protection without adding capacity can allow the kernel to kill a less replaceable process later.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →7. Treat swap and OOM scores as secondary controls
Provide controlled swap
Swap can absorb short-lived allocation spikes and give the kernel more options, but sustained swapping increases query latency and can make a game backend miss request deadlines. Confirm that swap exists with swapon --show, monitor swap-in and swap-out rates, and check whether systemd-oomd policy reacts to swap pressure. Swap is a pressure valve, not permission to configure a buffer pool larger than available resources.
Use oom_score_adj only for failure priority
Linux defines oom_score_adj as an adjustment to the badness score used for victim selection. A lower value can make mysqld less likely to be selected, but it does not reduce an allocation or create memory. It may simply transfer the kill to a gateway, queue, orchestration agent or another critical process. Treat it as a last-resort policy choice after capacity and cgroup settings are correct, and document the operational trade-off.
8. Validate the fix under the workload that caused the kill
- Persist the selected MySQL values and service limits, then record the configuration change and rollback value.
- Exercise the peak workload or a safe reproduction with the expected connection count and largest transactions.
- Watch host memory, cgroup
memory.current,memory.events, swap activity, PSI and MySQL RSS together. - Check query latency, temporary-table creation, disk spills, replication lag and connection refusals; a server that survives by queueing every request is not necessarily healthy.
- Review kernel, MySQL, systemd and systemd-oomd journals after the test for new pressure or kill events.
Keep the change only when peak usage remains below the applicable limit with a reserve and the workload’s latency and throughput remain acceptable. Recheck after schema changes, new services, traffic growth or a change in replication topology.
Which remediation should you choose?
| Option | Peak-memory effect | Performance or availability trade-off | Restart needed? | Blast radius and reversibility |
|---|---|---|---|---|
Reduce innodb_buffer_pool_size |
Directly lowers the largest common allocation | More disk reads and potentially higher latency | Often no; MySQL supports online resizing | Usually limited to MySQL and easy to measure or reverse |
Lower max_connections or add pooling |
Caps connection-related peaks | Excess requests queue or are rejected | Dynamic for new connection attempts; persist configuration | Application behavior changes, but the limit is reversible |
| Reduce per-thread and temporary-table buffers | Reduces burst allocation per active session | More disk-based work or slower complex queries | Depends on the variable | Server-wide query impact; change incrementally |
| Raise the cgroup or service limit | Adds available headroom within the host’s capacity | Consumes more infrastructure memory and may shift risk to the host | Usually requires a service-manager or deployment update | Affects scheduling and neighboring workloads |
| Add or tune swap | Absorbs some short-lived pressure | Can produce severe latency during sustained swapping | Usually no MySQL restart | System-wide I/O impact; reversible with monitoring |
Change oom_score_adj |
Does not reduce memory use | Changes which process dies when memory is exhausted | No, but service-manager policy may overwrite it | Can sacrifice another critical service; last resort |
Common failure patterns and their fixes
“I lowered the buffer pool, but MySQL is still killed.”
Check max_connections, peak Threads_connected, per-thread buffers, temporary tables, replication workers and the cgroup limit. A buffer-pool reduction cannot offset hundreds of concurrent sessions each allocating large sort, join or temporary-table memory.
“The host has free RAM, but the container dies.”
Read memory.max, memory.current and memory.events in the service’s cgroup. Increase the container limit only if the host budget supports it; otherwise reduce MySQL’s budget to fit the existing ceiling.
“There is no kernel OOM message.”
Check systemd-oomd status and its journal, then inspect unit properties and drop-ins for managed-OOM settings. A userspace kill may occur before the kernel emits an OOM record.
“The server survives but becomes unusably slow.”
Measure swap activity, PSI, disk temporary tables and query latency. Swap and very small buffers can prevent a kill while causing unacceptable stalls. Restore capacity or tune the workload rather than treating survival alone as success.
“The configured limit looks safe from idle measurements.”
Reproduce the traffic burst that caused the incident and size from its peak RSS and cgroup usage. Idle memory is not evidence that a connection storm or replication catch-up will fit.
Recommended Free Tools
Quick Recap
A repeatable operating checklist
- Identify whether the event was host OOM, cgroup OOM or systemd-oomd.
- Save the killed PID, timestamp, memory limit, RSS, swap and connection peak.
- Inventory the buffer pool, global caches, per-thread buffers, temporary-table limits, thread stack and replication or Performance Schema overhead.
- Calculate a conservative budget and include the operating system, filesystem cache, co-resident services and safety reserve.
- Reduce the buffer pool, connection ceiling or oversized per-thread buffers until the measured peak fits.
- Raise a cgroup limit only when host capacity and neighboring workloads permit it.
- Use swap for transient pressure and OOM-score changes only to express a deliberate failure priority.
- Validate under peak traffic and recheck after every material workload or deployment change.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
