Strange VIOS memory consumption - Aix

This is a discussion on Strange VIOS memory consumption - Aix ; Hello to everybody, I've got a strange problem with a VIOS 1.5.1.1-FP-10.1. The problem is related to memory consumption, that is very high, even if this VIOS is virtualizing only a couple of VSCSI and a couple of SEA. Preamble: ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Strange VIOS memory consumption

  1. Strange VIOS memory consumption

    Hello to everybody,

    I've got a strange problem with a VIOS 1.5.1.1-FP-10.1.

    The problem is related to memory consumption, that is very high, even
    if this VIOS is virtualizing only a couple of VSCSI and a couple of
    SEA.

    Preamble:

    - everything occurred after the creation of the second SEA (which I
    controlled, destroyed and recreated - so nothing is wrong with that)

    - the environment is made of six VIOS (same level, similar
    configuration) and this is the only one presenting this problem


    This is part of topas output:

    Kernel 0.4 |# | Reads 1
    Rawin 0
    User 0.1 |# | Writes 2
    Ttyout 44
    Wait 0.0 | | Forks 0
    Igets 0
    Idle 99.5 |############################| Execs 0
    Namei 0
    Physc = 0.00 %Entc= 0.7 Runqueue 1.0
    Dirblk 0
    Waitqueue 0.0
    Network KBPS I-Pack O-Pack KB-In KB-Out
    en3 0.3 1.5 1.5 0.1 0.2 PAGING
    MEMORY
    lo0 0.0 0.0 0.0 0.0 0.0 Faults 0
    Real,MB 2048
    Steals 0 %
    Comp 39.9
    Disk Busy% KBPS TPS KB-Read KB-Writ PgspIn 0 %
    Noncomp 3.3
    hdisk2 0.0 0.0 0.0 0.0 0.0 PgspOut 0 %
    Client 3.3
    hdisk7 0.0 0.0 0.0 0.0 0.0 PageIn 0
    hdisk6 0.0 0.0 0.0 0.0 0.0 PageOut 0
    PAGING SPACE
    hdisk8 0.0 0.0 0.0 0.0 0.0 Sios 0
    Size,MB 1536
    %
    Used 0.0
    Name PID CPU% PgSp Owner NFS (calls/sec) %
    Free 100.0

    As you can see % Comp is 39.9 and it is stable on that value (more or
    less), and this is OK.

    I have regular errors on PAGING (Faults is always over 0).

    This "stable" situation was achieved creating another LV for paging
    space (Paging01) and removing the old Paging00, so now the paging
    space is equal to hd6 + Paging01 (2GB).

    Before this "solution", that stabilised the memory consumption I had
    many more faults on paging (even if paging space has never been used)
    and the memory consumption went increasing until the system went
    inaccessible (the ssh session lasted until 75% of % Comp, then
    freeezed).

    The system uptime now is 2 days, and it "seemes" to be stable.


    Finally the question is: "Has anyone some idea on why this is
    happening?"


    Thanks in advance,

    Thomas

  2. Re: Strange VIOS memory consumption

    On 06/30/2008 10:19 AM, TomTom wrote:
    > Hello to everybody,
    >
    > I've got a strange problem with a VIOS 1.5.1.1-FP-10.1.
    >
    > The problem is related to memory consumption, that is very high, even
    > if this VIOS is virtualizing only a couple of VSCSI and a couple of
    > SEA.


    That may be but not evident from anything you presented so far.

    > As you can see % Comp is 39.9 and it is stable on that value (more or
    > less), and this is OK.


    The value only shows the composition of memory - i.e. the ratio of the
    file cache vs. computational memory.

    For a RDBMS, this can be 97% and still be perfectly understandable and
    operational.

    > I have regular errors on PAGING (Faults is always over 0).


    A non-zero value for fault/s does not necessarily indicate a error
    condition or performance related problem.

    > This "stable" situation was achieved creating another LV for paging
    > space (Paging01) and removing the old Paging00, so now the paging
    > space is equal to hd6 + Paging01 (2GB).


    No wonder you're having problems, you had a system with a relatively
    small memory configuration with a tiny paging space. If you have a large
    memory footprint (active virtual memory), you could easily run out of
    paging.

    For such a small amount of real memory, I would start of with 4GB of paging.

    The higher the confidence level you have that paging will not occur, the
    closer I would configure the paging space size to the real memory size.

    For performance reasons, paging spaces should be evenly sized, and it
    does not seem as if you followed this rule.

    > Before this "solution", that stabilised the memory consumption I had
    > many more faults on paging (even if paging space has never been used)
    > and the memory consumption went increasing until the system went
    > inaccessible (the ssh session lasted until 75% of % Comp, then
    > freeezed).


    Adding a paging space did not decrease the number of faults, despite
    what you may think.

    > Finally the question is: "Has anyone some idea on why this is
    > happening?"


    As a wild guess, you are likely running out of paging due to application
    memory requirements.

    You should post the following output when your system is under strain:
    lsps -a
    svmon -G
    vmstat 1 30
    and if SAR is enabled:
    sar
    sar -q

    cheers
    Niel

  3. Re: Strange VIOS memory consumption

    On Jul 1, 12:14*am, Niel Lambrechts wrote:
    > On 06/30/2008 10:19 AM, TomTom wrote:
    >
    > > Hello to everybody,

    >
    > > I've got a strange problem with a VIOS 1.5.1.1-FP-10.1.

    >
    > > The problem is related to memory consumption, that is very high, even
    > > if this VIOS is virtualizing only a couple of VSCSI and a couple of
    > > SEA.

    >
    > That may be but not evident from anything you presented so far.
    >
    > > As you can see % Comp is 39.9 and it is stable on that value (more or
    > > less), and this is OK.

    >
    > The value only shows the composition of memory - i.e. the ratio of the
    > file cache vs. computational memory.
    >
    > For a RDBMS, this can be 97% and still be perfectly understandable and
    > operational.
    >
    > > I have regular errors on PAGING (Faults is always over 0).

    >
    > A non-zero value for fault/s does not necessarily indicate a error
    > condition or performance related problem.
    >
    > > This "stable" situation was achieved creating another LV for paging
    > > space (Paging01) and removing the old Paging00, so now the paging
    > > space is equal to hd6 + Paging01 (2GB).

    >
    > No wonder you're having problems, you had a system with a relatively
    > small memory configuration with a tiny paging space. If you have a large
    > memory footprint (active virtual memory), you could easily run out of
    > paging.
    >
    > For such a small amount of real memory, I would start of with 4GB of paging.
    >
    > The higher the confidence level you have that paging will not occur, the
    > closer I would configure the paging space size to the real memory size.
    >
    > For performance reasons, paging spaces should be evenly sized, and it
    > does not seem as if you followed this rule.
    >
    > > Before this "solution", that stabilised the memory consumption I had
    > > many more faults on paging (even if paging space has never been used)
    > > and the memory consumption went increasing until the system went
    > > inaccessible (the ssh session lasted until 75% of % Comp, then
    > > freeezed).

    >
    > Adding a paging space did not decrease the number of faults, despite
    > what you may think.
    >
    > > Finally the question is: "Has anyone some idea on why this is
    > > happening?"

    >
    > As a wild guess, you are likely running out of paging due to application
    > memory requirements.
    >
    > You should post the following output when your system is under strain:
    > lsps -a
    > svmon -G
    > vmstat 1 30
    > and if SAR is enabled:
    > sar
    > sar -q
    >
    > cheers
    > Niel




    Thanks Niel,

    the system is running normally and nothing changed from Monday.

    This VIOS (together with another VIOS) gives connectivity (VSCSI and
    Ethernet) to only 2 client partitions at the moment, so I think that
    the amount of RAM is enough (2GB) together with paging space (1.5GB).

    Consider that I have another 2 dual-VIOS p570 in which VIOSs are
    giving connectivity to many more LPARs with the same amount of RAM/
    pgspace and nothing wrong has ever happened.

    So what i don't understand is why this VIOS behaved so badly on
    Monday, I think it could be another "IT mistery" that sometimes
    happens :-).



    By the way, here it is what you asked for:


    # lsps -a
    Page Space Physical Volume Volume Group Size %Used Active
    Auto Type
    paging01 hdisk0 rootvg 1024MB 1 yes
    yes lv
    hd6 hdisk0 rootvg 512MB 1 yes
    yes lv


    # svmon -G
    size inuse free pin virtual
    memory 524288 229291 294997 154041 202542
    pg space 393216 972

    work pers clnt other
    pin 130235 0 0 23806
    in use 202542 0 26749

    PageSize PoolSize inuse pgsp pin virtual
    s 4 KB - 128683 972 68905 101934
    m 64 KB - 6288 0 5321 6288


    # vmstat 1 30

    System configuration: lcpu=4 mem=2048MB ent=0.60

    kthr memory page faults
    cpu
    ----- ----------- ------------------------ ------------
    -----------------------
    r b avm fre re pi po fr sr cy in sy cs us sy id wa
    pc ec
    3 0 202611 294871 0 0 0 0 0 0 14 69 169 0 0 99 0
    0.00 0.7
    3 0 202611 294871 0 0 0 0 0 0 11 27 166 0 0 99 0
    0.00 0.6
    4 0 202611 294871 0 0 0 0 0 0 18 25 185 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 9 21 164 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 8 22 161 0 0 99 0
    0.00 0.5
    3 0 202611 294871 0 0 0 0 0 0 9 21 162 0 0 99 0
    0.00 0.5
    4 0 202611 294871 0 0 0 0 0 0 71 25 285 0 0 99 0
    0.00 0.7
    3 0 202611 294871 0 0 0 0 0 0 10 47 183 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 9 33 164 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 10 21 166 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 12 23 167 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 10 21 160 0 0 99 0
    0.00 0.5
    3 0 202611 294871 0 0 0 0 0 0 11 23 162 0 0 99 0
    0.00 0.5
    3 0 202611 294871 0 0 0 0 0 0 12 22 170 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 16 23 176 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 12 21 166 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 9 24 163 0 0 99 0
    0.00 0.6
    3 0 202611 294871 0 0 0 0 0 0 10 122 203 0 1 99 0
    0.01 1.1
    3 0 202611 294871 0 0 0 0 0 0 10 24 173 0 0 99 0
    0.00 0.8
    3 0 202611 294871 0 0 0 0 0 0 30 31 199 0 1 99 0
    0.01 0.9
    kthr memory page faults
    cpu
    ----- ----------- ------------------------ ------------
    -----------------------
    r b avm fre re pi po fr sr cy in sy cs us sy id wa
    pc ec
    3 0 202612 294870 0 0 0 0 0 0 10 212 163 0 1 99 0
    0.01 1.1
    3 0 202612 294870 0 0 0 0 0 0 10 23 180 0 0 99 0
    0.00 0.8
    3 0 202612 294870 0 0 0 0 0 0 13 23 175 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 10 21 162 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 11 28 169 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 12 24 168 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 105 41 206 0 1 99 0
    0.01 1.4
    3 0 202612 294870 0 0 0 0 0 0 10 21 159 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 9 31 168 0 0 99 0
    0.00 0.6
    3 0 202612 294870 0 0 0 0 0 0 10 21 160 0 0 99 0
    0.00 0.5



    Thanks,



    Thomas


  4. Re: Strange VIOS memory consumption

    On 2 Jul, 10:48, TomTom wrote:
    > On Jul 1, 12:14*am, Niel Lambrechts wrote:
    >
    >
    >
    >
    >
    > > On 06/30/2008 10:19 AM, TomTom wrote:

    >
    > > > Hello to everybody,

    >
    > > > I've got a strange problem with a VIOS 1.5.1.1-FP-10.1.

    >
    > > > The problem is related to memory consumption, that is very high, even
    > > > if this VIOS is virtualizing only a couple of VSCSI and a couple of
    > > > SEA.

    >
    > > That may be but not evident from anything you presented so far.

    >
    > > > As you can see % Comp is 39.9 and it is stable on that value (more or
    > > > less), and this is OK.

    >
    > > The value only shows the composition of memory - i.e. the ratio of the
    > > file cache vs. computational memory.

    >
    > > For a RDBMS, this can be 97% and still be perfectly understandable and
    > > operational.

    >
    > > > I have regular errors on PAGING (Faults is always over 0).

    >
    > > A non-zero value for fault/s does not necessarily indicate a error
    > > condition or performance related problem.

    >
    > > > This "stable" situation was achieved creating another LV for paging
    > > > space (Paging01) and removing the old Paging00, so now the paging
    > > > space is equal to hd6 + Paging01 (2GB).

    >
    > > No wonder you're having problems, you had a system with a relatively
    > > small memory configuration with a tiny paging space. If you have a large
    > > memory footprint (active virtual memory), you could easily run out of
    > > paging.

    >
    > > For such a small amount of real memory, I would start of with 4GB of paging.

    >
    > > The higher the confidence level you have that paging will not occur, the
    > > closer I would configure the paging space size to the real memory size.

    >
    > > For performance reasons, paging spaces should be evenly sized, and it
    > > does not seem as if you followed this rule.

    >
    > > > Before this "solution", that stabilised the memory consumption I had
    > > > many more faults on paging (even if paging space has never been used)
    > > > and the memory consumption went increasing until the system went
    > > > inaccessible (the ssh session lasted until 75% of % Comp, then
    > > > freeezed).

    >
    > > Adding a paging space did not decrease the number of faults, despite
    > > what you may think.

    >
    > > > Finally the question is: "Has anyone some idea on why this is
    > > > happening?"

    >
    > > As a wild guess, you are likely running out of paging due to application
    > > memory requirements.

    >
    > > You should post the following output when your system is under strain:
    > > lsps -a
    > > svmon -G
    > > vmstat 1 30
    > > and if SAR is enabled:
    > > sar
    > > sar -q

    >
    > > cheers
    > > Niel

    >
    > Thanks Niel,
    >
    > the system is running normally and nothing changed from Monday.
    >
    > This VIOS (together with another VIOS) gives connectivity (VSCSI and
    > Ethernet) to only 2 client partitions at the moment, so I think that
    > the amount of RAM is enough (2GB) together with paging space (1.5GB).
    >
    > Consider that I have another 2 dual-VIOS p570 in which VIOSs are
    > giving connectivity to many more LPARs with the same amount of RAM/
    > pgspace and nothing wrong has ever happened.
    >
    > So what i don't understand is why this VIOS behaved so badly on
    > Monday, I think it could be another "IT mistery" that sometimes
    > happens :-).
    >
    > By the way, here it is what you asked for:
    >
    > # lsps -a
    > Page Space * * *Physical Volume * Volume Group * *Size %Used Active
    > Auto *Type
    > paging01 * * * *hdisk0 * * * * * *rootvg * * * *1024MB * * 1 * yes
    > yes * *lv
    > hd6 * * * * * * hdisk0 * * * * * *rootvg * * * * 512MB * * 1 * yes
    > yes * *lv
    >
    > # svmon -G
    > * * * * * * * *size * * *inuse * * * free ** * *pin * *virtual
    > memory * * * 524288 * * 229291 * * 294997 * * 154041 * * 202542
    > pg space * * 393216 * * * *972
    >
    > * * * * * * * *work * * * pers * * * clnt ** *other
    > pin * * * * *130235 * * * * *0 * * * * *0 * * *23806
    > in use * * * 202542 * * * * *0 * * *26749
    >
    > PageSize * PoolSize * * *inuse * * * pgsp * * * *pin * *virtual
    > s * 4 KB * * * * *- * * 128683 * * * *972 * **68905 * * 101934
    > m *64 KB * * * * *- * * * 6288 * * * * *0 ** * 5321 * * * 6288
    >
    > # vmstat 1 30
    >
    > System configuration: lcpu=4 mem=2048MB ent=0.60
    >
    > kthr * *memory * * * * * * *page * * * * * * *faults
    > cpu
    > ----- ----------- ------------------------ ------------
    > -----------------------
    > *r *b * avm * fre *re *pi *po *fr * sr *cy *in * sy *cs us sy id wa
    > pc * *ec
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *14 * 69 169 *0 *0 99 *0
    > 0.00 * 0.7
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *11 * 27 166 *0 *0 99 *0
    > 0.00 * 0.6
    > *4 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *18 * 25 185 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 * 9 * 21 164 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 * 8 * 22 161 *0 *0 99 *0
    > 0.00 * 0.5
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 * 9 * 21 162 *0 *0 99 *0
    > 0.00 * 0.5
    > *4 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *71 * 25 285 *0 *0 99 *0
    > 0.00 * 0.7
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 47 183 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 * 9 * 33 164 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 21 166 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *12 * 23 167 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 21 160 *0 *0 99 *0
    > 0.00 * 0.5
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *11 * 23 162 *0 *0 99 *0
    > 0.00 * 0.5
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *12 * 22 170 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *16 * 23 176 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *12 * 21 166 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 * 9 * 24 163 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *10 *122 203 *0 *1 99 *0
    > 0.01 * 1.1
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 24 173 *0 *0 99 *0
    > 0.00 * 0.8
    > *3 *0 202611 294871 * 0 * 0 * 0 * 0 * *0 * 0 *30 * 31 199 *0 *1 99 *0
    > 0.01 * 0.9
    > kthr * *memory * * * * * * *page * * * * * * *faults
    > cpu
    > ----- ----------- ------------------------ ------------
    > -----------------------
    > *r *b * avm * fre *re *pi *po *fr * sr *cy *in * sy *cs us sy id wa
    > pc * *ec
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *10 *212 163 *0 *1 99 *0
    > 0.01 * 1.1
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 23 180 *0 *0 99 *0
    > 0.00 * 0.8
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *13 * 23 175 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 21 162 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *11 * 28 169 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *12 * 24 168 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 105 * 41206 *0 *1 99 *0
    > 0.01 * 1.4
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 21 159 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 * 9 * 31 168 *0 *0 99 *0
    > 0.00 * 0.6
    > *3 *0 202612 294870 * 0 * 0 * 0 * 0 * *0 * 0 *10 * 21 160 *0 *0 99 *0
    > 0.00 * 0.5
    >
    > Thanks,
    >
    > Thomas- Hide quoted text -
    >
    > - Show quoted text -



    Hi,

    I just wanted to add that a VIO server can run quite comfortably with
    a very small amount of memory especially if you only have a handful of
    'virtualizations' (for want of a better word) going on.

    We were running ours with 768MB !! but have now upped to 1GB as with
    768MB it did run out of memory when we started to add extra vhosts
    etc. We had maybe 8 or 9 vhosts, one SEA. I cant remember exactly
    as we seem to add more every day.

    Id have though 2GB was more than enough from your description of what
    you are doing.

    I also dont think we upped the paging from the default (512MB I think
    but am not logged in at the moment so cant be sure).

    However maybe VIO 1.5 needs more memory. We are still on 1.3 and 1.4
    and are in the process of upgrading.

    Regards,
    Scott

  5. Re: Strange VIOS memory consumption

    On 07/02/2008 11:48 AM, TomTom wrote:
    > On Jul 1, 12:14 am, Niel Lambrechts wrote:
    >> On 06/30/2008 10:19 AM, TomTom wrote:


    > the system is running normally and nothing changed from Monday.
    >
    > This VIOS (together with another VIOS) gives connectivity (VSCSI and
    > Ethernet) to only 2 client partitions at the moment, so I think that
    > the amount of RAM is enough (2GB) together with paging space (1.5GB).


    I disagree. You should be using at least 4GB paging for such an
    important server, anything under 2GB is just madness.

    > Consider that I have another 2 dual-VIOS p570 in which VIOSs are
    > giving connectivity to many more LPARs with the same amount of RAM/
    > pgspace and nothing wrong has ever happened.


    You already had one totally unexplained outage.

    If you have a sufficiently sized paging space, performance would degrade
    first (giving you a chance to investigate / recover / capture
    information) before a crash.

    > So what i don't understand is why this VIOS behaved so badly on
    > Monday, I think it could be another "IT mistery" that sometimes
    > happens :-).


    Given enough effort, they can always be explained...

    > By the way, here it is what you asked for:


    Except it shows output for an idle system, not "when the system is under
    strain"...

    You should save/post the output from those commands if you suspect
    similar issues again.

    The output also confirms that your paging spaces are not equally sized -
    this is known to negatively affect performance of the round-robin based
    AIX paging scheme.

    cheers
    Niel

+ Reply to Thread