Re: total memory of children processes

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> I have tried the 4.0beta4 on the main server... looks pretty fine...
> before I have 28 services... now with the new checksum syntax it went up
> to 61.   It takes monit some seconds to do all the work.  The rc-file is
> nearly double in size ( w/o empty lines and comments).

wow! and if it takes a few seconds to do the work, maybe it's time
soon to look into optimizing the code.

> Process 'init' is running with pid [1]
>         Uptime: 8m  CPU: 0.0% Memory w/o children: 0.0% [144kB]
>         Children: 172 Memory w/ children: 22.0% [462200kB]
>         Monitoring status: monitored
>
> Seems to be okay... I have a 2GB machine with apaches and sambas
> (lots of!)... and it looks reasonable... but I canT really verify.

That doesn't look bad, extrapolating with my Linux I have 60 processes
running and 237704K memory used.

> But for Linux I donT really know what I can do.  There is something
> really wrong... "no, both twisted and wrong". )-:

Arghh :) Did you try the algorithm suggested by Arkadiusz? i.e.:

 sum= parent.rss;
 for child in parent.children do
    sum += child.rss - shared mem
 done

If it is hard to get this right before next week, I suggest one of the
following:

1) Remove totmem as a statement until it's fixed
2) Keep it as it is, but write a notice about the bug on Linux 
   in the STATUS file. BTW, does this statement work on *BSDs? Rory?
3) Wait with the 4.0 release until it's fixed

I think 2) would be my chooice. How about you?

> Something I donT like it that the services are not in the same order
> as in the config file.  They are actually quite twisted... and for
> 61 services (for now!) I need some order in it. (-:

If you use depend between services, they will be sorted in a depending
order, see p.y:check_depend(), I don't think it's anyway around this
sorting. If you do not use depend, the servicelist should contain the
service as they was written in monitrc but in reverse order(?).

-- 
Jan-Henrik Haukeland