Xymon Mailing List Archive search

Improving memory monitoring

list Steve Hill
Tue, 14 Apr 2015 15:56:57 +0100
Message-Id: <user-a5e24218871b@xymon.invalid>

On 14/04/15 15:11, Mike Burger wrote:
I'll say that I've never run into this...I've never had a system swap
memory out to disk unless active memory was utilized at a high
percentage...in either AIX or Linux.
It does spontaneously happen from time to time for me - may be the type of work loads these machines do - they do tend to have a fair amount of idle data in memory and the kernel quite rightly decides that using that for caches/buffers would be a better use.

Also, in situations where something _has_ used up a lot of RAM and therefore pushed stuff out to swap, Xymon continues to warn of high swap usage after that process has ended because the kernel obviously won't bother paging stuff back into the newly emptied RAM until it needs to.
Now, on the other side of this, to take a stab at the question, I'd
wager that, at present, you'd need to script such a test/alert..but I
would agree that it would be useful to be able to set an "alarm if
this or this" or an "alarm if this and this" type scenario. At
present, the only tests I can think of that allow this, "out of the
box" are the process monitors, where you can set minimum and maximum
thresholds.
Is there a way of setting analysis.cfg to use a script instead of the MEM* directives, or would that need to be a completely external job of some kind?

-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
    Email:            user-8cda31fbea61@xymon.invalid
    Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
    Email:            user-2675bcaab7d4@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
    Email:            user-126f03e2871f@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid