Your database is probably not what's eating your RAM
A 1.7 GB MariaDB process looked like the obvious culprit. The real problem was a PHP script with no memory limit and a server with no swap.
Open any server dashboard, sort by memory, and the database will be at the top. It almost always is. That is what a database does — it fills the cache you gave it and keeps pages resident so it does not have to read them off disk again. A database using memory is a database working.
So when a 6 GB box started feeling tight and the process list showed MariaDB at 1.7 GB, the obvious move was to shrink it. That would have been the wrong fix, and it would have made the server slower for no benefit at all.
What the numbers actually said
The 1.7 GB was almost entirely the InnoDB buffer pool, deliberately set to 1536 MB. Against 9.1 GB of data on disk, that is a 17% cache ratio — already small. Cutting it would mean more disk reads, more CPU spent waiting, and a slower panel, in exchange for RAM that nothing else was asking for.
The question worth asking is not "what is using the most memory" but "what ran out". Those are different questions with different answers, and only the second one is a problem.
Reading the OOM killer's mind
The kernel logs every out-of-memory kill, and the entry names both the victim and the size it had reached. On this box there was exactly one, and it was not the database:
kernel: Out of memory: Killed process 4135150 (php)
total-vm:4856284kB, anon-rss:4155572kB, file-rss:3840kB, UID:33A single PHP process had grown to 4.1 GB of anonymous memory. When it asked for more, the kernel had to free some, and it picks its victim by size — which on most servers means the database. The database was not the cause. It was the biggest thing standing next to the cause.
Why PHP could do that
PHP's command-line SAPI ships with memory_limit = -1. Not a large limit — no limit. Every cron worker, every maintenance script, every one-off php script.php you run over SSH has permission to allocate until the machine dies.
That is a reasonable default for a laptop and a terrible one for a server. The fix is one line in a conf.d file:
; /etc/php/8.3/cli/conf.d/99-limits.ini
memory_limit = 512MAnd why it was fatal instead of slow
The second half of the problem: the box had no swap at all. Zero. With even a small swapfile, a memory spike becomes a slowdown you can notice and investigate. Without one, the first allocation that cannot be satisfied is immediately fatal to something.
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstabSet vm.swappiness = 10 alongside it. That keeps swap as an emergency valve rather than something the kernel reaches for while there is still RAM — at the default of 60 it will happily page out warm cache and make everything slower for no reason.
The check that takes two minutes
dmesg -T | grep -i 'out of memory'— has anything actually been killed?free -m— is there swap at all?php -r 'echo ini_get("memory_limit");'— is the CLI unlimited?systemctl show -p MemoryCurrent— where is the memory really going?
If nothing has ever been OOM-killed, your biggest process is not a problem — it is a cache doing its job. Leave it alone and go find something that is actually broken.
Alien XP
Runs the servers behind AlphaPanel and writes up what breaks.
