dmesg and the OOM killer

The OOM killer is the Linux kernel’s last resort when the server runs out of free memory. It ends one process so the rest of the system can keep running. You use dmesg to see which process was chosen and when it happened, which is the first step toward fixing the real shortage of RAM.

On a VPS you have root, so you can read the kernel log yourself. On shared hosting you do not have root, and CloudLinux LVE already limits how much memory your account may use. In both cases the pattern is the same: something asked for more RAM than was free, and the kernel protected the box.

dmesg -T | grep -i -E ‘oom|killed process’ | tail

The -T flag prints readable timestamps. Look for a line that says “Killed process” along with a name and an anon-rss value. That name is the victim, not always the leak. A sibling PHP worker, a backup job, or a sudden spike of children may have pushed memory over the edge. Read a few lines above the kill for the invocation that tripped it. If older dmesg output was rotated away, journalctl -k -S today shows the same kernel stream for today.

What the OOM killer is telling you

The killer is not a bug. It means the guest or the account oversubscribed RAM. Large RSS processes such as mysqld or php-fpm are common victims because they hold the most memory when pressure peaks. Disabling the OOM killer is a poor idea copied from forums. The machine can deadlock instead, and then nothing answers at all.

Swap can turn a hard kill into a slow crawl. It is a pressure valve that buys time to notice the problem. It is not a second memory limit, and it will not give InnoDB a healthy buffer pool under load.

Do the memory math on paper

Count your PHP workers and multiply by each one’s memory_limit. That total must still leave room for MariaDB or MySQL, the operating system, and any backup that might run. Twenty children at 256M is already about 5 GB before the database. On a 2 GB VPS that plan cannot work. LiteSpeed lsphp follows the same arithmetic under a different name.

On shared hosting, LVE memory is your cap. You cannot tune the node’s OOM killer, but the account still fails when it exceeds its limit. Shrinking the worker pool or the PHP memory limit is the lever you control.

When it only dies at backup time

Nightly backups plus a mysqldump plus a full daytime worker count often explain an outage around 02:00. JetBackup may copy files while php-fpm still holds many children and mysqld still keeps a large buffer pool. Those three loads will not fit together on a small plan.

Lower the worker count in the backup window, avoid overlapping a full dump with the file backup, or add RAM. If mysqld is the victim every time, the buffer pool may be too large for the guest, or a query may be building a huge sort. If PHP is the victim, you likely have too many children or a plugin that leaks. Either way, the kernel did its job; the lasting fix is less concurrent demand or more memory.