Why MySQL / MariaDB Keeps Crashing on 1GB–2GB RAM VPS

I remember this one client who kept calling us every few days — his WordPress site kept going down. Not a high-traffic site, not running any heavy plugins, just a simple business website on a 1GB RAM VPS. He’d get a 502 Bad Gateway, or sometimes Error establishing a database connection. We’d restart MySQL, it would come back up, work fine for a day or two, then die again. The client was convinced his VPS was broken. “Maybe I should just get a new one?”

Sound familiar? This is one of the most common issues I see on small VPS instances — MySQL or MariaDB crashing on its own, with no clear error message. You check the MySQL error log and find nothing obviously wrong. You restart the service and it comes right back. But hours or days later, the same problem repeats. It’s incredibly frustrating.

Turns out, the culprit isn’t MySQL itself. It’s a Linux kernel feature called the OOM Killer — Out of Memory Killer — that’s quietly terminating your database process because your server ran out of RAM. And on a 1GB or 2GB VPS, running out of RAM is easier than you think.

In this article, we’ll break down exactly why this happens, how to prove it with log evidence, and what you can do about it — starting right now.

Symptoms & Error Messages You’ll See

Before we dive into solutions, let’s talk about what this actually looks like in the real world. This isn’t a straightforward error that gives you a clear message. Often the symptoms are subtle, which is what makes it so confusing.

Here are the most common symptoms:

• 502 Bad Gateway — Nginx/Apache can’t reach PHP-FPM or the backend
• Error establishing a database connection — your CMS can’t talk to MySQL
• MySQL service status: inactive (dead) — but no error in the MySQL log itself
• Website loads extremely slowly before eventually going completely down
• Entire server becomes sluggish — even SSH sessions feel laggy

The really frustrating part? When you restart MySQL (systemctl restart mysqld or systemctl restart mariadb), everything works perfectly. The website loads fine. But a few hours or days later, the same issue comes back. Over and over.

Why MySQL / MariaDB Keeps Crashing on Low-RAM VPS

OOM Killer: The Silent Executioner

Think of your VPS as a small apartment (1GB–2GB RAM). Inside this apartment live several “residents”: the operating system, your web server (Nginx/Apache), PHP-FPM, MySQL/MariaDB, and maybe some other services like Redis or cron jobs.

Each resident needs “floor space” (RAM) to do their work. As long as everyone fits, things are fine. But when the apartment gets too full, there’s a “landlord” called OOM Killer that decides who gets evicted — and it picks whoever is taking up the most space.

MySQL/MariaDB is usually the largest occupant because of its InnoDB buffer pool, query cache, and active connections. So it becomes the first victim when OOM Killer kicks in.

When OOM Killer terminates the MySQL process, there’s no graceful shutdown, no error message in the MySQL log. The process simply vanishes. It’s killed at the kernel level, and MySQL never gets a chance to log what happened.

How OOM Killer Works

Technically, here’s what happens:

1. The Linux kernel continuously monitors RAM usage
2. When RAM is nearly exhausted and the system can’t allocate memory for a process that needs it
3. OOM Killer is activated and starts calculating a “score” for each process
4. The process with the highest score (usually the one consuming the most RAM) gets terminated
5. MySQL/MariaDB typically scores highest because of its buffer pool and active connections

The frustrating part is that OOM Killer doesn’t leave obvious traces in the MySQL log. You won’t see errors in /var/log/mysql/error.log or /var/log/mariadb/mariadb.log. The “death notice” for MySQL is recorded elsewhere — specifically in dmesg or /var/log/messages.

How to Check OOM Killer Logs

This is the first thing you should do if you suspect MySQL died from OOM. Run these commands:

dmesg | grep -i oom

Or on systemd-based systems:

dmesg | grep -i "out of memory"

Here’s what OOM Killer output actually looks like:

[Jul 20 03:42:15] Out of memory: Kill process 1245 (mysqld) score 850 or sacrifice child
[Jul 20 03:42:15] Killed process 1245 (mysqld) total-vm:892412kB, anon-rss:651204kB, file-rss:0kB, shmem-rss:0kB

See that? That’s the “death warrant.” Linux is telling you: process mysqld (PID 1245) was killed because it consumed too much RAM (651MB). You can also check /var/log/messages or /var/log/syslog:

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

Or for Debian/Ubuntu:

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

You can also verify MySQL is actually down (not just temporarily unresponsive):

systemctl status mysqld

or for MariaDB:

systemctl status mariadb

If the status shows inactive (dead) but there’s no recent restart timestamp, OOM Killer most likely did the dirty work.

Why 1GB–2GB VPS Instances Are Vulnerable

Why does this happen more often on small VPS instances? Simple answer: headroom.

On a larger VPS (4GB, 8GB, etc.), there’s enough “spare” RAM to handle usage spikes. But on a 1GB–2GB VPS, the margin is razor-thin.

Here’s an estimate of RAM usage on a typical 1GB VPS running a standard web stack:

Service	Estimated RAM	Notes
OS + Systemd	~100–150 MB	Minimum to boot
Nginx / Apache	~30–80 MB	Depends on config & traffic
PHP-FPM	~50–150 MB	Depends on max_children
MySQL / MariaDB	~200–400 MB	Depends on innodb_buffer_pool_size
SSH + System processes	~50–80 MB	Always running
Total	~430–860 MB	Very close to 1GB limit

Now imagine traffic increases — PHP-FPM spawns more workers, MySQL handles more queries, Nginx serves more requests. The “free” RAM disappears instantly, and OOM Killer starts doing its job.

Concrete Solutions: 3 Essential Steps

Solution 1: Set Up a SWAP File

SWAP is like a “spare room” on your hard disk that can serve as “extra RAM” when physical RAM runs out. Yes, it’s slower than real RAM, but it’s infinitely better than having MySQL killed by OOM.

If your VPS doesn’t have SWAP, this is step one — mandatory. I typically set up 1GB–2GB of SWAP for a 1GB RAM VPS.

Check if SWAP already exists:

free -h

Example output when there’s no SWAP:

              total        used        free      shared  buff/cache   available
Mem:          988Mi       412Mi        85Mi        12Mi       490Mi       530Mi
Swap:            0B          0B          0B

See the Swap line — if it shows 0B, there’s no SWAP. If there is SWAP, you can skip this step or add more if needed.

Steps to create a 1GB SWAP file:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Verify SWAP is active:

free -h

You should now see the Swap line showing 1GB total:

              total        used        free      shared  buff/cache   available
Mem:          988Mi       412Mi        85Mi        12Mi       490Mi       530Mi
Swap:         1.0Gi        15Mi      1.0Gi

Make SWAP persistent across reboots:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Optimize SWAP usage (optional but recommended):

You can control when Linux starts using SWAP with vm.swappiness. The default is usually 60, meaning Linux starts using SWAP when 40% of RAM is used. For VPS, I set it to 10 so SWAP only kicks in when things are truly desperate:

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Warning: SWAP is not a permanent solution for insufficient RAM. It’s a “shock absorber” to prevent MySQL from being killed instantly. If your site genuinely needs more RAM, consider upgrading your VPS.

Solution 2: Tune innodb_buffer_pool_size

innodb_buffer_pool_size is MySQL’s “main home” for caching data and indexes in RAM. The default can be quite large — some distributions set it to 256MB or even 128MB. On a 1GB VPS, that’s way too much.

My rule of thumb: innodb_buffer_pool_size should never exceed 50% of total RAM. For a 1GB VPS, 128MB–256MB is plenty. For a 2GB VPS, you can go up to 384MB–512MB.

Tuning steps:

Open the MySQL/MariaDB configuration file:

For MySQL:

sudo nano /etc/mysql/my.cnf

For MariaDB:

sudo nano /etc/my.cnf

Or on AlmaLinux/RHEL-based:

sudo nano /etc/my.cnf.d/mariadb-server.cnf

Find the [mysqld] section and add/modify these parameters:

[mysqld]
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
innodb_log_buffer_size = 8M
key_buffer_size = 32M
max_allowed_packet = 64M

Quick explanation of each parameter:

Parameter	Function	Recommended (1GB VPS)	Recommended (2GB VPS)
innodb_buffer_pool_size	RAM for InnoDB data & index cache	128M	256M–384M
innodb_log_file_size	Redo log size (write performance)	32M	64M
innodb_log_buffer_size	Buffer for redo log before flush	8M	16M
key_buffer_size	RAM for MyISAM index cache	32M	64M
max_allowed_packet	Maximum packet size	64M	64M

After editing, restart MySQL/MariaDB:

sudo systemctl restart mysqld

or for MariaDB:

sudo systemctl restart mariadb

Verify the new settings took effect:

mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Expected output:

+---------------------+-----------+
| Variable_name       | Value     |
+---------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+---------------------+-----------+

134217728 bytes = 128MB. If this matches what you set, you’re good.

Solution 3: Limit max_connections

Every MySQL connection consumes RAM — typically 2–5MB per connection, depending on the queries being executed. If max_connections is set too high, MySQL can “eat” all available RAM just maintaining connections.

On a 1GB VPS, I recommend setting max_connections to around 30–50. For a 2GB VPS, you can go up to 50–100.

Edit the same config file (/etc/mysql/my.cnf or /etc/my.cnf):

[mysqld]
max_connections = 30
wait_timeout = 60
interactive_timeout = 60

The wait_timeout and interactive_timeout parameters ensure idle connections are closed after 60 seconds, preventing RAM waste on inactive connections.

Restart MySQL/MariaDB:

sudo systemctl restart mysqld

Verify:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"

You can also monitor active connections anytime:

mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"

Additional Steps Often Overlooked

Check Other Services Eating Your RAM

It’s not always MySQL that’s the problem. Other services can also be culprits. Check real-time RAM usage:

sudo ps aux --sort=-%mem | head -20

Example output:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1245  2.1 28.5 892412 281200 ?       Sl   03:20   1:42 /usr/sbin/mysqld
root       892  0.8 12.3 231456 121504 ?       Ss   03:20   0:45 /usr/sbin/httpd
root      1034  1.2  8.1 156789  80123 ?       S    03:20   0:33 php-fpm: pool www
redis      567  0.3  4.2  75632  41234 ?       Ssl  03:20   0:12 redis-server 127.0.0.1:6379

From this output, you can see who’s using the most RAM. MySQL is the biggest consumer (28.5%), but httpd (12.3%) and php-fpm (8.1%) are also contributing.

If you’re running Redis, make sure it’s not consuming too much RAM either:

sudo nano /etc/redis/redis.conf

Find maxmemory and set it to a reasonable value (e.g., 64MB for a 1GB VPS):

maxmemory 64mb
maxmemory-policy allkeys-lru

Troubleshooting Table: MySQL Keeps Crashing

Symptom	Likely Cause	How to Check	Solution
MySQL dies without error log	OOM Killer	dmesg | grep -i oom	Add SWAP + tune buffer pool
Intermittent 502 Bad Gateway	PHP-FPM running out of RAM	sudo ps aux --sort=-%mem	Lower pm.max_children
MySQL dies during traffic spikes	max_connections too high	SHOW STATUS LIKE 'Threads_connected'	Reduce max_connections
Server lag + MySQL dies	No SWAP + low RAM	free -h	Add 1–2GB SWAP
MySQL restarts automatically but frequently	Watchdog/restart policy active	systemctl status mysqld	Fix root cause, don’t rely on restarts

Pro Tips & Warnings

When Should You Upgrade Your VPS?

Let’s be honest — all the solutions above are “pain relievers.” If your website is genuinely getting heavy (lots of plugins, increasing traffic, multiple sites on one VPS), it’s time to upgrade your RAM.

Signs you need an upgrade:

• SWAP usage consistently above 50%
• MySQL crashes more than twice a week even after tuning
• Website load time keeps increasing without config changes
• You’re running more than one website on a 1GB VPS

Consider upgrading to a 4GB VPS or using a managed database service (like AWS RDS, DigitalOcean Managed Database) if budget allows.

Related Articles

• How to Fix 502 Bad Gateway on VPS
• Error Establishing a Database Connection — Complete Guide
• Nginx Reverse Proxy Error: Upstream Timed Out
• How to Reduce RAM Usage on cPanel