svmon -G versus svmon -S - Aix

This is a discussion on svmon -G versus svmon -S - Aix ; I am writing a small script to get memory consumption by user but without counting twice shared segments. Shared segments will be accounted to the first user (and main user order can be specified on the command line). All that ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: svmon -G versus svmon -S

  1. svmon -G versus svmon -S

    I am writing a small script to get memory consumption by user but
    without counting twice shared segments. Shared segments will be
    accounted to the first user (and main user order can be specified on
    the command line). All that should work fine and is not very difficult
    with svmon.

    The only problem is that svmon is not accurate. On all my boxes, aix
    5.3 or aix 5.2, I get a significant discrepancy between svmon -G and
    svmon -S :

    [root@xmndv03]:/tmp #svmon -G
    size inuse free pin virtual
    memory 1572864 1564248 8616 748452 886700
    pg space 1048576 22108

    work pers clnt
    pin 748452 0 0
    in use 872556 0 691692

    [root@xmndv03]:/tmp #svmon -S | awk 'NF>2{t=t+$(NF-0)}END{print t}'
    811634 # virtual
    [root@xmndv03]:/tmp #svmon -S | awk 'NF>2{t=t+$(NF-1)}END{print t}'
    22108 # pg space
    [root@xmndv03]:/tmp #svmon -S | awk 'NF>2{t=t+$(NF-2)}END{print t}'
    673338 # pin
    [root@xmndv03]:/tmp #svmon -S | awk 'NF>2{t=t+$(NF-3)}END{print t}'
    1489415 # inuse

    So a difference of around 10%. Pg space only is OK. Results are worst
    with svmon -U, -P or -C (that appear as subset of svmon -S), identical
    with svmon -D. Is there anyone without this problem on aix boxes ? I
    ran out of idea (I have no 16 MB pages, primary and secondary segments
    are properly handled by svmon). It looks like I will start a first
    version of my script with the user "unknown" :-(


  2. Re: svmon -G versus svmon -S

    gep wrote:
    > The only problem is that svmon is not accurate. On all my boxes, aix
    > 5.3 or aix 5.2, I get a significant discrepancy between svmon -G and
    > svmon -S :


    For a start, you rerun svmon for every field. (you do not indicate if
    the server is busy, but it could make a difference) In my experience,
    there is not that much difference between svmon -P, svmon -U and ps vg's
    output.

    I usually do:
    # svmon -P > svmonP.txt && svmon -U > svmonU.txt && psvg > psvg.txt

    regards,
    Niel

  3. Re: svmon -G versus svmon -S


    Niel Lambrechts a écrit :

    > For a start, you rerun svmon for every field. (you do not indicate if
    > the server is busy


    Thank you for your answer.

    I can run the commands at everytime, there is always a big
    discreçancy. For the example above, I ran it on Sunday afternoon :
    there was no activity.

    > but it could make a difference) In my experience,
    > there is not that much difference between svmon -P, svmon -U and ps vg's
    > output.


    Run the commands on your own boxes, we will see.

    >
    > I usually do:
    > # svmon -P > svmonP.txt && svmon -U > svmonU.txt && psvg > psvg.txt
    >


    svmon -P and -U are subset of svmon -S (after you sort duplicate
    segments). So results are worst (in fact most of system segments can
    only be found in svmon -S). I took my box with the less segments
    (around 17000) and I ran svmon -D on all segments to have all frame
    details (This enabled me to check that secondary segments were not
    counted twice in svmon ; in fact there are not counted at all). I ran
    also svmon -C on all processes. I didn't find any missing frames. All
    svmon files are avalaible but I doubt you are interested in them.

    It looks like svmon -G is only a quick compilation of global system
    counters, while other options are looking at system kernel structures.
    Somehow all objects are not in these structures.

    I am really interested in a machine without this problem. My aix boxes
    are in fact partitions of a LPAR system.

    Regards,
    Gerard.


  4. Re: svmon -G versus svmon -S

    gep wrote:
    > It looks like svmon -G is only a quick compilation of global system
    > counters, while other options are looking at system kernel structures.
    > Somehow all objects are not in these structures.


    I once wrote a perl script which counted each segment in either svmon -U
    and svmon -P and flagged them shared as they became shared (if the same
    segment really was used twice). I correlated this to "ps vg" output,
    using the RSS and TRS fields.

    These matched well enough - the discrepancies could be explained due to
    the quick changing nature of memory between the execution of each command.

    I have not yet tried to use svmon -S, will do the same and post results.

    Regards,
    Niel

+ Reply to Thread