Cloudron Forum

You should see it in the app logs around that timeframe what happened

@msbt yes, thanks for reaching out, will take a look.

@rmdes yes, I am not sure why. It doesn't happen in any of our demo servers or managed services. Quite strange. It could also be that maybe others have hit it but have not noticed it (since it only causes a CPU spike..) but clearly it's a bug since it's been fixed upstream.

@mastadamus I will bump up the memory limit for vault. https://learn.hashicorp.com/tutorials/vault/reference-architecture says 4-8GB is recommended. Currently, the cloudron package runs at 256MB!

Also, as you guessed, it's only the vault container that is dying and the server is not affected (I guess that's one of the main benefits of running in containers, a single app cannot bring down a system).

@nebulon I thought it was perhaps the Broken Links Checker on one of my WordPress installs, as as @marcusquinn noted it's widely known to sometimes cause such issues, but I've disabled that and I'm still getting these /mysql was restarted (OOM) (although they don't seem to appear in the event log?).

I note that the most recent one happened 5 minutes after my backups are due to start, and the other previous two times it's been 7-9mins before updates are due to run.

I wonder if either of those (backup/ update) processes might have something to do with it?

I guess I could just give mysql more memory and not worry, but be nice to know what's happening and why...

@d19dotca Yes, the limits are there to protect against the noisy neighbor problem which exists when many processes are competing for the same resources and ONE uses up more than their fair share.

Technically we could have all 30 Apps be set to 1+GB on a 16GB RAM system and it would work fine until one App behaved badly. Then the system would be in trouble as the OOM killer would select a potentially critical service to kill.

With limits, the system is happy, and the killing happens in containers instead.