MariaDB Stops sometimes

SYSTEM INFORMATION
OS type and version Debian 10
Webmin version 2.105
Virtualmin version 7.9.0

After reading another topic about the same issue, @Joe asked me to create a new topic.

The command dmesg give me a tons of info but I didn’t see MariaDB with an error. Do I have to run the command when MariaDB is stopped?
I saw different OOM Kill Process, like Systemd-journal or php-cgi8.2.

Also this line at the end:

File /run/log/journal/0ef30511d74646618d92e464efb187ce/system.journal corrupted or uncleanly shut down, renaming and replacing.
[5019071.191809] systemd[1]: Started Journal Service.

You don’t have enough memory. (We have to assume Mariadb is also being killed by the OOM killer. The OOM killer appears random to users, though there is a heuristic for trying to kill the least active process that frees enough memory to avoid worse problems. An out-of-memory condition is a disastrous condition. There’s nothing good the kernel can do in that circumstance, so killing processes to free up memory is a compromise.)

You either need to reduce memory usage, or increase memory.

You can, as a stopgap measure, add swap memory to the system, to stop the OOM killer. Swap is very slow compared to real memory, but software that isn’t even running is the slowest software.

1 Like

I have 8GB.
My Wordpress websites are not very big tho. I have 9 actives for now. I guess that a plugin is taking more memory than it should…
Is there a way to know more detail what happens exactly? to know if it’s a plugin or a different service running.

Seems very likely something is misbehaving. 8GB is probably fine for a few WordPress sites.

Assuming you haven’t wildly altered the Mariadb or PHP configuration to consume a lot more memory. And, assuming you don’t have mod_php installed (mod_php is a big memory user, even if you aren’t using it).

top is where I usually start. You can sort by memory (press M, that’s <shift>-m).

I didn’t see the module “mod_php” in the Modules of PHP 7.3, 7.4 and 8.2.

Here’s the result of top.

19077 mysql 20 0 1624396 234572 6832 S 0.0 2.9 27:58.65 mysqld
8832 root 20 0 184192 170408 7332 S 0.0 2.1 0:02.30 /usr/share/webm
893 drip 20 0 328992 136752 111836 S 0.0 1.7 0:18.44 php-cgi8.2
897 drip 20 0 371192 136404 108860 S 0.0 1.7 0:15.25 php-cgi8.2
907 skoolie+ 20 0 328216 134144 93312 S 0.0 1.7 0:44.75 php-cgi7.3
910 skoolie+ 20 0 332072 132160 87524 S 0.0 1.7 0:37.15 php-cgi7.3
15462 root 20 0 1058608 128908 4868 S 0.3 1.6 178:13.10 fail2ban-server
10241 alienga+ 20 0 371296 127748 99956 S 0.0 1.6 0:07.00 php-cgi8.2
882 skoolie+ 20 0 329172 127168 85572 S 0.0 1.6 0:59.81 php-cgi7.3
961 alienga+ 20 0 329284 126412 100744 S 0.0 1.6 0:11.73 php-cgi8.2
890 skoolie+ 20 0 329412 125632 84040 S 0.0 1.6 1:01.32 php-cgi7.3
5732 drip 20 0 328244 125364 101368 S 0.0 1.6 0:06.79 php-cgi8.2
23279 dripmar+ 20 0 317552 124244 94456 S 0.0 1.6 0:07.97 php-cgi7.4
23283 dripmar+ 20 0 317116 118812 89212 S 0.0 1.5 0:08.08 php-cgi7.4
3256 dripmar+ 20 0 317968 117408 87088 S 0.0 1.5 0:06.97 php-cgi7.4
25980 drip 20 0 327640 116136 92328 S 0.0 1.5 0:05.41 php-cgi8.2
6197 alienga+ 20 0 329760 108824 83488 S 0.0 1.4 0:22.73 php-cgi8.2
19406 alienga+ 20 0 329476 108108 82860 S 0.0 1.4 0:25.34 php-cgi8.2
8831 root 20 0 112528 101988 4368 S 0.0 1.3 0:00.98 /usr/share/webm
1894 nomadfe+ 20 0 317368 100068 69876 S 0.0 1.3 0:10.43 php-cgi7.3
24882 nomadfe+ 20 0 246924 93476 59972 S 0.0 1.3 0:00.00 /usr/share/webm
1894 nomadfe+ 20 0 317368 100068 69876 S 0.0 1.3 0:10.43 php-cgi7.3
24882 nomadfe+ 20 0 246924 93476 59972 S 0.0 1.2 0:39.05 php-cgi7.3
2532 nomadfe+ 20 0 318740 92428 61044 S 0.0 1.2 0:32.69 php-cgi7.3
4121 nomadfe+ 20 0 316296 87508 58240 S 0.0 1.1 0:05.15 php-cgi7.3
945 sallyre+ 20 0 304008 74584 57772 S 0.0 0.9 0:10.35 php-cgi7.3
876 bind 20 0 257288 74500 0 S 0.7 0.9 67:22.83 named
837 visual-+ 20 0 311372 71728 47968 S 0.0 0.9 0:15.10 php-cgi7.4
949 sallyre+ 20 0 303712 69776 53176 S 0.0 0.9 0:10.63 php-cgi7.3
948 visual-+ 20 0 309232 69752 48332 S 0.0 0.9 0:11.58 php-cgi7.4
846 visual-+ 20 0 312072 68268 45320 S 0.0 0.9 0:16.52 php-cgi7.4
838 visual-+ 20 0 310920 63856 40616 S 0.0 0.8 0:06.55 php-cgi7.4
842 visual-+ 20 0 308868 63280 42164 S 0.0 0.8 0:05.38 php-cgi7.4
14471 sallyre+ 20 0 303492 60992 44628 S 0.0 0.8 0:01.82 php-cgi7.3
14475 sallyre+ 20 0 229664 59748 43468 S 0.0 0.7 0:01.44 php-cgi7.3
841 visual-+ 20 0 308872 57880 36680 S 0.0 0.7 0:05.09 php-cgi7.4
9104 root 20 0 47776 39976 11024 R 38.9 0.5 0:01.17 letsencrypt
19100 root 20 0 79996 39260 16292 S 1.3 0.5 8:58.60 systemd-journal
2649 shivaco+ 20 0 220944 28888 23012 S 0.0 0.4 0:00.05 php-cgi7.4
8659 root 20 0 36116 27616 6228 S 0.0 0.3 0:00.05 perl
28595 root 20 0 37012 24452 2088 S 0.0 0.3 0:40.06 perl
8652 root 20 0 28132 23504 3196 S 0.0 0.3 0:00.10 shellserver.pl

I had experienced this issue too. Maria’s RAM usage generally low as 500 MB, but when ‘something i have no clue on’ happens, it gets killed by OOM.

I edited service file to restart whenever it crashes. Never looked back since then.

/lib/systemd/system/mariadb.service

Restart=always
RestartSec=3

restarting a stopped service is OK - but you should really resolve what is causing it to stop. Find and fix the bug (lazy code) in the code that is causing it. The problem will not go away you are just trying to hide it.

1 Like

Automatically restarting a service that is randomly being killed by the OOM killer guarantees that some day you’ll have data loss.

Safer to add a bunch of swap memory (like twice your current memory) until you figure out why you’re running out. (Though if you still run out after doubling available memory, it’s something truly pathological going wrong, and it should be apparent what it is if you spend a few minutes looking at what’s using memory.)

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.