Re: [gentoo-user] mysqld invoked oom-killer

[kashani]

On 7/21/2011 10:22 AM, Grant wrote:
>>> I ran into an out of memory problem.  The first mention of it in the
>>> kernel log is "mysqld invoked oom-killer".  I haven't run into this
>>> before.  I do have a swap partition but I don't activate it based on
>>> something I read previously that I later found out was wrong so I
>>> suppose I should activate it.  Is fstab the way to do that?  I have a
>>> commented line in there for swap.
> ...
>> If you're running any other servers that utilize MySQL like Apache or
>> something, check its access logs to see if you had an abnormal number
>> of connections. Bruteforce hacking or some kind of flooding/DOS attack
>> might cause it to use more memory than it ordinarily would.
>
> I don't know why I didn't check the apache2 error log before, but I
> got the following entry 2 seconds before the server became
> unresponsive:
>
> [error] server reached MaxClients setting, consider raising the
> MaxClients setting
>
> I use the default 256 for MaxClients.  This confirms the server was
> brought down by too many child processes consuming too much memory.
> Looking back at the access_log, it's clear this condition was caused
> by the single IP which requested one of my pages about 300 times over
> the course of 1 minute.  This caused my entire server to lock up for
> hours until I rebooted it.
>
> I hesitate to reduce MaxClients from 256.  I think my server should be
> able to handle it since it's the default.  So I need to prevent my
> apache2 child processes from consuming so much memory?  apache2 was
> restarted about an hour before the lockup so it had a pretty fresh
> start.  I do use mod_perl which is a memory hog from what I
> understand.  Do I just need more RAM?

	Most people do not think about this correctly. Can your server run 
10000 Apache processes? No, not enough resources. 1000? No, same 
problem. 256? I'd say no based on this thread. If you're not going to 
set it at 10000 why try to keep it at 256?
	Next image a grocery store with 256 checkout lanes, but only four 
cashiers. Four cashiers trying to run that many lanes is actually slower 
than having only four lanes. However 32 lanes could faster than 4. 
People can have their groceries setup, baggers aren't getting in the 
way, etc. The analogy breaks down a bit, but you get the point.

	There is no performance gain in configuring for concurrency your 
hardware and software can not support.

kashani