My Database Crashed Twice! A Life-or-Death Rescue Log on a 2-Core 8GB Server

Hi everyone, this is Neo.

Today I want to share a truly “thrilling” real-world incident.

Here’s what happened: to set up a multilingual setup for my e-commerce site, I spun up a Hostinger VPS with pretty decent specs — 2 cores, 8GB RAM. Installed aaPanel (宝塔) on it, running one WordPress site.

I figured these specs would be way more than enough for a WP site, right? Then, right as I was about to fire up the GTranslate translation plugin for the initial site-wide translation, the server decided to perform a dramatic “death on the spot.”

The site wouldn’t load. Database connection failed. I rushed into the aaPanel dashboard — and holy cow, the load average was pinned at 100%!

Load 100%

At that moment I was internally screaming: I bought an 8GB RAM machine! We’d barely started and it’s already dead?

After a heart-pounding round of troubleshooting and some deep consultation with a tech guru, I finally figured out what was really going on. If you also run your e-commerce site on a VPS, this post might just save your life at the worst possible moment.

1. The Crime Scene: Why Was the Load at 100%?

A lot of beginners (including me, back then) see “load 100%” and immediately think: “Oh no, the CPU is maxed out — do I need to pay to upgrade?”

But after I calmed down and actually studied aaPanel’s monitoring charts, I spotted something weird:

Even though the load average was alarmingly red, the CPU usage wasn’t actually maxed out.

And when I looked at the process list, the #1 CPU consumer wasn’t MySQL — it was a process called kswapd0, eating 12.95% of the CPU. Right behind it were MySQL and a security monitoring agent.

Neo’s take: Who Is kswapd0?

Think of it like this: you hired a housekeeper (kswapd0) to keep the room (memory) tidy.

Normally the room is spacious, the housekeeper works at a relaxed pace, no sweat. But suddenly you cram a bunch of furniture into the room (the WordPress translation task), and the room fills up. Now the housekeeper panics and starts frantically hauling furniture into the hallway (the disk swap partition), then hauling it back in, over and over.

The housekeeper is exhausted (high CPU usage), and the hallway is completely blocked (I/O bottleneck) — so nobody can get in or out.

So, that “100% load” you see isn’t really the CPU being overwhelmed — it’s the memory being exhausted, with the system thrashing data like crazy and causing a massive “traffic jam.”

2. Why Is MySQL Always the First to Be Sacrificed?

During this incident, my MySQL database crashed twice. Every time I restarted it, it ran for a bit and died again.

Looking at the system logs (dmesg), I found this chilling line in red:

Out of memory: Killed process 147502 (mysqld)

That’s the legendary OOM Killer.

Neo’s take: What Is the OOM Killer?

Linux has a ruthless killer called the OOM Killer. Its job: when system memory is about to run out and the machine is on the verge of freezing, it kills the process eating the most memory to keep the system alive.

And on our server, who eats the most memory? Without a doubt — MySQL.

So when kswapd0 can’t keep up and memory is completely exhausted, the OOM Killer pulls the trigger and takes out MySQL.

That’s why your site suddenly shows “database connection error,” and why restarting MySQL seems to fix it — only for it to die again a while later. Because the root cause (insufficient memory) is still there, the killer will come back.

3. Pitfall Survival Guide: How to Keep Your Server From “Dropping Dead”

Now that we know the disease, we can write the prescription. For small-to-medium VPS configs with 2-8GB of RAM, these three moves work really well:

1. Put a “Leash” on MySQL

Many VPS default MySQL configs are tuned for high performance, so MySQL gobbles up as much memory as it can. We need to manually cap it.

In aaPanel, find the MySQL config (my.cnf) and focus on adjusting innodb_buffer_pool_size.

  • By default: it may consume 50%-70% of physical memory.
  • Recommendation: on an 8GB machine that also runs PHP and other services, set it to roughly 2GB-4GB. On a 2GB machine, 256MB-512MB is enough.

In one sentence: don’t let MySQL eat its fill — leave some food for everyone else.

2. Turn Off the Unnecessary “Vampires”

Looking back at my process list, I found a process called monarx-agent, and aaPanel’s built-in site_total (site monitoring) was also eating resources.

When server resources are tight, these monitoring tools become the straw that breaks the camel’s back.

  • My advice: on low-memory machines, disable aaPanel’s “system monitoring” feature, or uninstall unnecessary security plugins. Keep the site running first; worry about monitoring second.

3. Check Your Swap (Virtual Memory)

Swap is slow, sure, but when physical memory is exhausted at a critical moment, it’s the server’s “ICU ward.”

  • Check: use the free -m command to see whether swap is enabled.
  • Advice: if it isn’t enabled, or it’s too small, definitely add some. A good rule of thumb is about 1x your physical memory (e.g., 8GB RAM paired with 4-8GB swap). It’s slower, but at least MySQL won’t get outright killed.

Hands-on: How to Enable Swap?

Method 1: aaPanel (recommended for beginners) In aaPanel’s app store, search for “Linux Toolbox,” install it, open it, click “Swap/Virtual Memory,” and set it based on your physical RAM (1x physical memory is the recommendation).

Method 2: Command Line (for the hardcore) If you prefer typing commands, follow this flow:

  1. Create a 4GB file: dd if=/dev/zero of=/swapfile bs=1M count=4096
  2. Set permissions: chmod 600 /swapfile
  3. Format it as swap: mkswap /swapfile
  4. Enable it: swapon /swapfile
  5. Finally, don’t forget to add it to /etc/fstab so it takes effect automatically on boot.

4. Summary

Running an e-commerce site means technical pitfalls are unavoidable. This “database down” ordeal taught me something:

Having beefy server specs doesn’t mean you can just kick back and relax.

If you’ve also hit “load 100% but CPU isn’t high” or “MySQL keeps stopping on its own,” immediately check these three things:

  1. Is kswapd0 running wild? (Memory is exhausted)
  2. Is there Out of memory in the system logs? (MySQL got killed)
  3. Is innodb_buffer_pool_size set way too large?

I hope this postmortem helps you skip some detours — every hour you save from server surgery is an hour you can spend closing deals!

I’m Neo — let’s keep leveling up together on the road to going global with e-commerce.