FYI: how to prevent mysql from oom-killer

[Reindl Harald]

Am 13.04.2012 15:47, schrieb Mihamina Rakotomandimby:
> On 04/13/2012 03:17 PM, Reindl Harald wrote:
>> with one single command you can protect processes from get killed
>> i started to run this every 15 minutes to make sure it is also
>> active after restarts
> 
> I understand your issue, but isn'there a configuration way to just limit the memory usage of MySQL?

no, you did not understand the issue nor my intention
intention was not "i have a problem and needs help"
intention was "if someone may have a problem this is the help"

the problem is that ANOTHER process or many of them triggering
a OOM situation and after that the kernel killing randomly
processes to prevent from a system crash

the proc-setting is to prevent that this randomly process
is mysqld instead the process which is eating up your memory
_____________________

as real world example (i was there)

* machine has 9 GB RAM
* machine is a dbmail-server
* mysqld has assigend buffer-pools and so on up to 7 GB
* someone tryies to copy a 2 GB attachment in drafts folder
* the memory usage of imapd explodes
* the first times OOM killer is killing imapd
* at least the OOM is killing mysqld

you want NOT killed mysqld in this situation
you want not killed mysqld damaging tables becuase you are
running out of memory because too much httpd-processes
eating up your memory

at least - you never want to get randomly killed mysqld

pgrep -f "/usr/libexec/mysqld" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done

is preventing you from this happening
maybe you want prevent such a situation before it happend

i searched how can i proctect our servers, found a solution and
thought it is a good idea to publish it on 3 mailing-lists
where many users could need it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120413/216374d8/attachment.sig>