I'm doing something similar in my Solaris zones, calculating the percentage of RSS per zone versus the cap on the zone and reporting the percentage. That way we have a good threshold to alarm off, i.e. 90% of the capped memory is being used.

From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Vernon Everett Sent: Tuesday, July 24, 2012 7:04 AM To: Henrik Størner Cc: xymon at xymon.com Subject: Re: [Xymon] Memory monitoring - capped zone

Hi Henrik

I was hoping you would respond. :-) My comprehension of C is shaky at best, which is why I asked the list. Here's my understanding of the problem, and how I think we can improve things. I am happy to code any changes to the script side, but there may be some updates required in the C code.

Using prtconf to get installed memory makes sense. In a capped zone, it will show the cap. In an uncapped zone, it will show the total memory, as seen from the global zone. (This may not really be the available memory because of other zones, but that is the potential memory available, and the best we can get at the moment.)

However, whenever we check the memory within a zone, capped, or uncapped, it interrogates the kernel. The kernel returns all the free memory it can see. From the global zone! The problem arises in cases where there is more memory free than the cap size. e.g. 2Gb cap, with 3Gb free memory.

So how to establish how much memory is really free in a capped zone. If we run prstat -Z, the last lines will show the memory footprint of the zone. (If you run it in the global zone, it shows the memory footprint of all the zones.) The memory cap, less the footprint, should give us the free memory within the zone.

I do not believe there is any way from within a zone, to determine if you are capped or not capped, but that shouldn't make a difference. However, it's easy to deteremine if you are in a zone. "zoneadm list" should be a single line, not equal to "global". A non-zero exit code, or a return of global, indicates you are in a global zone, or a system not running zones.

Translating to pseudo code if [ is a zone ] and [ not global zone ] then use prtconf to get memory footprint calculate free memory using prtconf and memory footprint else use existing method to determine free memory fi

Thoughts and feedback appreciated.

Regards Vernon

On 24 July 2012 15:58, Henrik Størner <henrik at hswn.dk<mailto:henrik at hswn.dk>> wrote: On 24-07-2012 05<tel:24-07-2012%2005>:45, Vernon Everett wrote: Hi all

I think I have eventually figured out how we can monitor memory in a meaningful way in a capped zone. Looking at the "client data" sent to the server, can anybody tell me which data are used to calculate the figures, and percentage used for memory?

It depends on what operating system is monitored - memory monitoring is one of the most messy parts of the Xymon client, simply because there is no standard way of reporting it from the various operating systems.

Look at the OS-specific code in xymond/client/*.c

E.g. on Solaris, it uses the "prtconf" data to determine the amount of RAM installed, the "memory" data to figure out how much is used, and the "swap" or "swaplist" data for swap information (depending on what version of the OS and client is installed).

Regards, Henrik

Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon

-- "Accept the challenges so that you can feel the exhilaration of victory"

• General George Patton