If you saw an OOM anything, it’s getting OOMkill’d by the kernel trying to keep the machine up. Check syslogs and dmesg, and it should say what was killed, and there’s your problem container. You probably have a memory leak, so just check your container stats every so often and see what is growing out of control with memory usage.

Enable swap regardless. Would also help to know what you’re running.

I would start all containers except one. If everything works that one is the cause of the problem. Keep trying with a different container every time.

Are you running them from your user session? If so, when you log out it will stop your processes, unless you have enabled ‘linger’ mode.

If you’re seeing an OOM killer messsage note that it doesn’t necessarily kill the problem process, by default the kernel hands out memory upon requestt, regardless of whether it has ram to back the allocation. When a process then writes to the memory (at some later time) and the kernel determines that there is no physical ram to store that write, it then invokes OOM Killer. This then selects a process and kills it. MySQL (and MariaDB) use large quantities of ram for cache, and by default the kernel lies about how much is available, so they often end up using more than the system can handle.

If you have many databases in containers, set memory limits for those containers, that should make all the databases play nicer together. Additionally , you may want to disable overcommit in the kernel, this will cause the kernel to return out of memory to a process attempting to allocate ram and stop lying about free ram to processes that ask, often greatly increasing stability.

Install atop, basically ‘top’ on steroids with history… It defaults to capturing performance data every 5 minutes, I usually change it to 1 minute on production systems.