Monit mongrel limit

What do other people use as their memory limit for mongrel in monit?
I’m using these settings below and it seems like I’m getting a lot of
emails and restarts. Should I bumb up the totalmem limit to 80 or 100?

    if totalmem is greater than 60.0 MB for 5 cycles then

restart # eating up memory?
if cpu is greater than 50% for 2 cycles then
alert # send an email to admin
if cpu is greater than 80% for 3 cycles then
restart # hung process?
if loadavg(5min) greater than 10 for 8 cycles then
restart # bad, bad, bad
if 3 restarts within 5 cycles then
timeout # something is wrong, call the sys-
admin

    if failed port 8000 protocol http
            with timeout 10 seconds
            then restart
    group mongrel

I’m using 70 and 90MB in two different apps. So far it’s been good for
me.

AEM

On 10/30/07, jnunemaker [email protected] wrote:

    if cpu is greater than 80% for 3 cycles then
    group mongrel


Adrian Esteban Madrid
Lead Developer, Prefab Markets
http://www.prefabmarkets.com

I set the default memory limit to 110Mb on engineyard slices. Memory
usage also varied on 32bit vs 64bit platforms. If you are on 32bit
then mongrels use about 10% less emory then on 64bit servers.

Cheers-
-Ezra

Yeah, I’m thinking that 60 might be too small. I’ll bump it up.

jnunemaker escribió:

    if failed port 8000 protocol http
            with timeout 10 seconds
            then restart
    group mongrel

[OT] This configuration I thought it isn’t very correct. Imagine if you
disable your web application(for example with: cap deploy:web:disable)
and then you make changes while monit is trying to restart mongrel it
can be a bit annoying. Maybe will be put an “and not exists
public/system/maintenance.html” (pseudocode not real code) :wink:

Regards

Yeah, or you can disable the monitoring of mongrel before a longer
change. I believe because all the mongrel checks have the group
‘mongrel’ I can start/stop monitoring on them all at once without
turning monit on and off.

We use a limit of around 110 - 130
It really sucks as a solution though…