Re: [hobbit] OSF physical memory, good reference

[Anton Burkhalter <anton.burkhalter (at) gmx.net>]

Ok, here we are :

osadmin (at) test1> swapon -s
Swap partition /dev/disk/dsk0b:
   Allocated space:      1572864 pages (12.00GB)
   In-use space:           51996 pages (  3%)
   Free space:           1520868 pages ( 96%)


Total swap allocation:
   Allocated space:      1572864 pages (12.00GB)
   In-use space:           51996 pages (  3%)
   Available space:      1520868 pages ( 96%)
osadmin (at) test1 #

---------------------------------------------------

osadmin (at) test2> swapon -s
Swap partition /dev/disk/dsk1b:
   Allocated space:      1048576 pages (8.00GB)
   In-use space:          199699 pages ( 19%)
   Free space:            848877 pages ( 80%)


Total swap allocation:
   Allocated space:      1048576 pages (8.00GB)
   In-use space:          199699 pages ( 19%)
   Available space:       848877 pages ( 80%)
osadmin (at) test2>

--------------------------------------------------
osadmin (at) test3> swapon -s
Swap partition /dev/disk/dsk3b:
   Allocated space:       868544 pages (6.63GB)
   In-use space:            8998 pages (  1%)
   Free space:            859546 pages ( 98%)

Swap partition /dev/disk/dsk7c:
   Allocated space:       901440 pages (6.88GB)
   In-use space:            9136 pages (  1%)
   Free space:            892304 pages ( 98%)


Total swap allocation:
   Allocated space:      1769984 pages (13.50GB)
   In-use space:           18134 pages (  1%)
   Available space:      1751850 pages ( 98%)
osadmin (at) test3>

--------------------------------------------------------------


osadmin (at) test4> swapon -s
Swap partition /dev/disk/dsk3b:
   Allocated space:       868544 pages (6.63GB)
   In-use space:          126384 pages ( 14%)
   Free space:            742160 pages ( 85%)

Swap partition /dev/disk/dsk6c:
   Allocated space:       901440 pages (6.88GB)
   In-use space:          125968 pages ( 13%)
   Free space:            775472 pages ( 86%)

Swap partition /dev/disk/dsk7c:
   Allocated space:       901440 pages (6.88GB)
   In-use space:          125603 pages ( 13%)
   Free space:            775837 pages ( 86%)


Total swap allocation:
   Allocated space:      2671424 pages (20.38GB)
   In-use space:          377955 pages ( 14%)
   Available space:      2293469 pages ( 85%)
osadmin (at) test4>

-------------------------------------------------

osadmin (at) test5> swapon -s
Swap partition /dev/disk/dsk5b:
   Allocated space:       868544 pages (6.63GB)
   In-use space:          108247 pages ( 12%)
   Free space:            760297 pages ( 87%)

Swap partition /dev/disk/dsk8c:
   Allocated space:       901440 pages (6.88GB)
   In-use space:          108482 pages ( 12%)
   Free space:            792958 pages ( 87%)


Total swap allocation:
   Allocated space:      1769984 pages (13.50GB)
   In-use space:          216729 pages ( 12%)
   Available space:      1553255 pages ( 87%)
osadmin (at) test5>

-------------------------------

Regards,
Tony

> Thanks, but I'd really like to see what the "swapon -s" output looks
> like. This script works fine for a client that generates the status 
> messages itself, but it's too heavy for the Hobbit client design.
>
> (My idea with the Hobbit client is to have as little "intelligence"
> in the client as possible - I prefer to do very little processing of
> the data on the client, and just forward all of the raw output to the
> Hobbit server. That lets the admin see exactly what the system
> says about itself - sometimes these commands report things that 
> don't show up in the interpreted data used for the Hobbit status
> messages.  E.g. the "vmstat -P" output on OSF has a detailed break-down 
> of how the memory is used, which might be useful when you get a 
> memory-alert and need to know WHY all of the memory is gone. 
> Instead of having to login to the box and run commands to figure it out, 
> you can dig into the raw client-data which is available directly in 
> Hobbit, and get the information you need. The fact that it also lets
> you centralize the alert configuration and potentially do some
> event correlation between different systems is just an added bonus).
>
>
> Regards,
> Henrik
>