Resolving MySQL/MariaDB 'Out of Memory' (OOM Killer) Crashes

It is the most dreaded alert a system administrator can receive: "Error Establishing a Database Connection." You scramble to load your client's website, only to find a white screen of death. You log into your dedicated server via SSH, restart the MySQL or MariaDB service, and the site magically comes back online. You breathe a sigh of relief, assuming it was a random glitch. But 48 hours later, the exact same crash happens again.

Your database isn't being hacked, and your hardware isn't failing. You are the victim of a premeditated assassination by the Linux kernel.

When a Linux system completely runs out of physical memory (RAM), it faces a critical choice: either allow the entire server to freeze and kernel panic, or sacrifice a massive process to free up memory and save the operating system. To execute this, Linux deploys the Out of Memory (OOM) Killer.

Because your MySQL or MariaDB database is almost always the largest consumer of RAM on a web server, the OOM Killer targets it first. It ruthlessly terminates the mysqld process, instantly taking your web applications offline.

In this comprehensive, step-by-step tutorial, we will uncover exactly how to identify an OOM Killer event, demystify the complex mathematics of MySQL memory allocation, teach you how to safely tweak your configuration to prevent memory bloat, and show you how to deploy a high-speed NVMe swap file as a fail-safe on your EPY Host dedicated server.

What You'll Learn

Phase 1: Diagnosing the Crime Scene

Before we start changing configuration files, we must prove beyond a shadow of a doubt that the OOM Killer is actually the culprit. A database can crash for many reasons (corrupted tables, bad storage blocks, or configuration typos). We need to check the kernel's syslog.

Step 1: Query the Kernel Ring Buffer (dmesg)

The dmesg command prints messages from the Linux kernel. If the OOM Killer was invoked recently, its fingerprints will be logged here.

Run the following command in your terminal:

dmesg -T | grep -i 'killed process'
                                    

(Note: The -T flag translates the timestamp into a human-readable format).

If the OOM killer took down your database, you will see output that looks strikingly similar to this:

[Tue May 26 14:32:11 2026] Out of memory: Killed process 14592 (mysqld) total-vm:4892312kB, anon-rss:3910124kB, file-rss:0kB, shmem-rss:0kB, UID:27 pgtables:8112kB oom_score_adj:0
                                    

Step 2: Search the Historical System Logs

If the crash happened several days ago, the kernel ring buffer may have overwritten the event. In this case, you need to search your historical system logs.

For AlmaLinux / RHEL / CentOS:

grep -i 'out of memory' /var/log/messages
                                    

For Ubuntu / Debian:

grep -i 'out of memory' /var/log/syslog
                                    

Or, if your server uses journalctl:

journalctl -k | grep -i -e 'oom' -e 'killed process'
                                    

If you see mysqld or mariadbd listed next to an "Out of memory" entry, you have a definitive diagnosis. Your dedicated server is starving for RAM.

Phase 2: The Mathematics of MySQL Memory Usage

To enact a permanent MySQL out of memory fix, you have to understand how the database engine consumes RAM.

Memory in MySQL and MariaDB is divided into two distinct categories: Global Buffers and Per-Thread Buffers. The total memory your database could theoretically consume is calculated using this frightening formula:

Total RAM = Global Buffers + (Per-Thread Buffers x max_connections)

1. Global Buffers (The Base Load)

   These are memory pools allocated exactly once when the database starts up. They are shared among all connections.

   • innodb_buffer_pool_size: This is the undisputed king of RAM usage. It caches your database tables and indexes in memory to prevent slow disk reads. On a dedicated database server, this is usually set to 70% of total RAM.

   • key_buffer_size: Used for caching index blocks for the older MyISAM storage engine.

2. Per-Thread Buffers (The Multipliers)

   Every time a user visits your website, the application opens a connection (thread) to the database. For every single connection, MySQL allocates a specific amount of memory for sorting and joining data.

   • sort_buffer_size

   • read_buffer_size

   • join_buffer_size

The Fatal Flaw

The OOM Killer strikes when administrators blindly increase the max_connections variable to prevent "Too many connections" errors, without realizing the mathematical consequences.

If you have 50MB of Per-Thread Buffers and you set max_connections to 1000, your database could theoretically demand 50,000 MB (50 GB) of RAM the moment you get a traffic spike. If your server only has 32 GB of RAM, the Linux kernel will panic and execute the mysqld process.

Phase 3: Tweaking MySQL/MariaDB to Prevent Crashes

Now that we know the math, we need to enforce strict memory limits. We will do this by editing your primary configuration file.

Step 1: Locate Your Configuration File

Depending on your OS and whether you use MySQL or MariaDB, the configuration file is located in different places. Open it using nano or vi:

• Standard / AlmaLinux / CentOS: nano /etc/my.cnf

• Ubuntu / Debian (MySQL): nano /etc/mysql/mysql.conf.d/mysqld.cnf

• Ubuntu / Debian (MariaDB): nano /etc/mysql/mariadb.conf.d/50-server.cnf

Find the [mysqld] section. If any of the following variables do not exist, add them below [mysqld].

Step 2: Optimize the InnoDB Buffer Pool

If your dedicated server hosts both your web server (Apache/Nginx) and your database, you cannot dedicate 80% of your RAM to MySQL, or you will starve PHP and Nginx, causing another crash.

• Rule of Thumb for Shared Servers (Web + DB): Set this to 30% to 40% of your total server RAM.

• Rule of Thumb for Dedicated DB Servers: Set this to 70% of your total server RAM.

Assuming you have a 16 GB server hosting both a website and a database, set it to roughly 5 GB:

innodb_buffer_pool_size = 5G
                                    

(Note: Never set this higher than your physical RAM minus the OS overhead, or you will trigger the OOM killer immediately upon startup).

Step 3: Tame the Per-Thread Buffers

Many administrators mistakenly inflate these values hoping to speed up queries. In reality, setting these too high causes massive memory bloat and actually slows down the server due to allocation overhead. Keep these lean.

Add or modify these lines to enforce safe limits:

sort_buffer_size = 2M
read_buffer_size = 1M
join_buffer_size = 2M
read_rnd_buffer_size = 2M
                                    

By keeping these to 1M or 2M, each new connection consumes a tiny, predictable footprint.

Step 4: Cap the Max Connections

Do not set max_connections to an absurd number like 5000. If your site actually has 5000 concurrent database queries, you need a massive cluster, not a single configuration tweak.

For most medium-to-large business websites, 150 to 300 is plenty:

max_connections = 250
                                    

Step 5: Save and Restart

Save the file (Ctrl+O, Enter, Ctrl+X in nano) and restart the database service to apply the new memory limits.

For MariaDB:

systemctl restart mariadb
                                    

For MySQL:

systemctl restart mysql
                                    

Phase 4: Deploying the Ultimate Safety Net (Swap Space)

MariaDB crashing dedicated server resources happens because when RAM hits 100%, the OS has nowhere else to put data.

To completely prevent the OOM killer from executing your database, you must provide the kernel with an overflow valve. This is called Swap Space. Swap allows the kernel to take inactive data residing in RAM and temporarily move it to your storage drive.

Warning: Running a database heavily in swap will cause performance to plummet because storage drives are slower than RAM. However, a slow database is infinitely better than a crashed, offline database. Because EPY Host provisions dedicated servers with blazing-fast Enterprise NVMe drives, the performance penalty of swapping is significantly mitigated compared to older SATA SSDs.

Let's create a 4 GB swap file.

Step 1: Create the Swap File

We will use the dd command to create a block of zeroes on your primary NVMe drive. We use dd instead of fallocate because some modern file systems (like XFS) have compatibility issues with fallocate for swap files.

Run this command as root:

dd if=/dev/zero of=/swapfile bs=1M count=4096
                                    

(This creates a 4096 MB, or 4 GB, file. It may take a few seconds).

Step 2: Secure the Swap File

Swap space can contain sensitive data (like unencrypted database queries or passwords) that were pushed out of RAM. You must lock down the permissions so only the root user can read it.

chmod 600 /swapfile
                                    

Step 3: Format and Activate the Swap

Tell the Linux kernel to format this file as swap space:

mkswap /swapfile
                                    

Now, turn it on:

swapon /swapfile
                                    

Verify that the system recognizes your new overflow valve:

free -h
                                    

You should now see 4.0G listed next to the Swap: row.

Step 4: Make it Permanent

If you reboot your server right now, the swap file will be deactivated. We must add it to your File System Table (fstab).

Open /etc/fstab:

nano /etc/fstab
                                    

Add the following line to the absolute bottom of the file:

/swapfile swap swap defaults 0 0
                                    

Save and exit. Your server is now immune to sudden, catastrophic out-of-memory panics.

Step 5: Adjust the Swappiness (Optional but Recommended)

By default, the Linux kernel has a "swappiness" value of 60 (on a scale of 0 to 100). This means it is relatively eager to move data from RAM to your NVMe drive. For a database server, we want to keep data in RAM as much as possible, only using swap as an absolute last resort emergency valve.

Let's lower the swappiness to 10.

Open the sysctl configuration file:

nano /etc/sysctl.conf
                                    

Add this line to the bottom:

vm.swappiness = 10
                                    

Apply the changes immediately without rebooting:

sysctl -p
                                    

Phase 5: Monitoring and Verification

You have now mathematically capped MySQL's memory footprint and provided the kernel with an NVMe-backed safety net. To ensure your server is healthy, you should actively monitor it.

1. Monitor Live Usage with htop:

   Install htop if you haven't already (dnf install htop or apt install htop). Run the command htop and look at the memory bar at the top. You will see your RAM usage stabilize, and you can monitor if your system ever begins bleeding into your newly created Swap space (the red/yellow bar).

2. Audit with MySQLTuner:

   After your database has been running with these new settings for at least 24 hours (do not run it immediately after restarting the service), you should run MySQLTuner. This is a Perl script that analyzes your live traffic and suggests configuration changes.

   Download and run it:

   Bash Copy

   
   wget http://mysqltuner.pl/ -O mysqltuner.pl
   chmod +x mysqltuner.pl
   ./mysqltuner.pl
                                               

   Scroll down to the Performance Metrics section of the output. MySQLTuner will calculate your exact Maximum possible memory usage. If that number is safely below your server's total physical RAM, you have successfully eradicated the OOM Killer threat.

Conclusion

The Linux OOM Killer is not your enemy; it is a desperate survival mechanism trying to keep your server online when resources run dry. By taking the time to manually configure your innodb_buffer_pool_size and per-thread limits, you ensure that your database operates strictly within its designated boundaries. Coupled with an NVMe swap file, you guarantee that even the most aggressive viral traffic spikes will not result in a fatal process termination.

If you are consistently running into memory limits despite optimizing your configuration, it may be time to move away from shared application architecture.