monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: total memory of children processes


From: Jan-Henrik Haukeland
Subject: Re: total memory of children processes
Date: Fri, 12 Sep 2003 17:48:01 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

Christian Hopp <address@hidden> writes:

> But there are many network checks e.g. on a busy samba. Nothing to
> worry about! 

Okay, I will not worry then.

> There are still some makeup things... I use a large font in my
> browser.  When it comes to the columns with space, CR are inserted.
> That looks creepy. 

Hehe, I tought the movie "The Ring" (http://www.ring-themovie.com/)
was creepy, but having HTML rows/columns break with CR does also sound
pretty scary.

> Though, the table is everything else but too wide.

We could set a small 12/14 px. style-sheet font, I have checked in
this now. As a last resort we could increase the table width to 80-90%
(it's 70% now), but *that* looks creepy in *my* browser.

> Using a LCD I can hardly distinguish the white from the gray in the
> Process, Device, ... Lists.  We might want to make it a tone darker.

I must say it doesn't look that bad on my crt screen, as you can see
from: http://www.tildeslash.com/monit/beta/screenshoot.gif, but feel
free to experiment :)

> I did...
>
> sum= parent.drs + parent.trs - parent.share;
> for child in parent.children do
>     sum += child.drs + child.trs - child.share
> done
>
> ... with foo.drs+foo.trs=foo.rss... but wanted to see whats happening!
> This is less then Arkadiusz algorithm and less then before but still
> far too much...

Aha, I saw it now. Hmm, as a far shoot, could it have something to do
with the numbers in /proc/../statm beeing not 1024 bytes but some
different page size?

> Right now I got 260MB out of my 256+500MB mem in my LAP with that
> code.  But when I check with free just 150MB is in use!

Urk!

>> 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
>
> The cleanest way but too bad for the fortunate using Solaris. (-:
>
>> 2) Keep it as it is, but write a notice about the bug on Linux
>>    in the STATUS file. (...)
>
> And write a warning if the statement is used on Linux!
>
>> 3) Wait with the 4.0 release until it's fixed
>
> Wait until somebody tidies up the Linux Kernel code on this... I think
> Rasterman was once mentioning something about this problem, after too
> many people were complaining about E's memory consumption!
>
>> I think 2) would be my chooice. How about you?
>
> As I am one of the fortunate Solaris users I would also prefer
> 2)... but when it comes to clean code I would do the hard way, meaning 1).

Let's go for choice 2 and it's a good idea to put in a warning in the
parser, if the statement is used on Linux. You fix? Then we still are
up for a release Monday/Tuesday next week.

> Nope... it depends on your depends. (-: I have written a code
> preserving the order for status, by adding a next_conf and a
> statuslist_conf.  This requires just <services>*<pointersize> memory.
> And it works.

Yes, simply saving the servicelist in an optional variable++ *before*
check_depend is executed will let you keep the registred order. But
I'm not sure why this is important to do?

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]