Paging Space Anomaly in AIX 5.2 TL10
GeorgeD
I have just experienced a very strange paging space anomaly.
I have a LPAR which runs AIX5.2 TL10 on a p570. It has 12 GB RAM and 2
CPUs.
Paging is defined on the rootvg as 3 mirrored LVs (hd6, paging00,
paging01) each 2GB
in size.
The paging space was 70% full, and I thought that this would be a good
opportunity to
refactor the paging space into a single paging space of size 6GB and
increase it by
50%.
I started by increasing hd6 to 6GB.
I then ran swapoff on paging01 so that I could remove it.
I expected the used pages to migrate to hd6 or paging00. However,
neither increased in % used.
I then ran swapoff on paging00 so that I could remove it.
A similar thing happened - hd6 % used did not increase.
I thus managed to decrease the paging used from 70% to 24%.
I wondered what would happen if I swapped off hd6.
So I swapped on paging00, and swapped off hd6.
I ended up with 2% used on paging00.
To finish, I swapped on hd6, swapped off paging00, and removed
paging00 and paging01.
Somehow I managed to "compress" 70% of 6GB into 1% of 6GB.
If the paging space which was freed up was not actually being used,
why wasn't the
"paging space free-up" algorithm reclaiming it ?
Below are some traces at the various points in the process.
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging01 hdisk1 rootvg 2048MB 69 yes
yes lv
paging00 hdisk1 rootvg 2048MB 70 yes
yes lv
hd6 hdisk1 rootvg 2048MB 70 yes
yes lv
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging01 hdisk1 rootvg 2048MB 69 yes
yes lv
paging00 hdisk1 rootvg 2048MB 70 yes
yes lv
hd6 hdisk1 rootvg 6144MB 24 yes
yes lv
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging01 hdisk1 rootvg 2048MB 0 no
yes lv
paging00 hdisk1 rootvg 2048MB 70 yes
yes lv
hd6 hdisk1 rootvg 6144MB 24 yes
yes lv
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging01 hdisk1 rootvg 2048MB 0
no no lv
paging00 hdisk1 rootvg 2048MB 0
no no lv
hd6 hdisk1 rootvg 6144MB 24 yes
yes lv
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging01 hdisk1 rootvg 2048MB 0
no no lv
paging00 hdisk1 rootvg 2048MB 2
yes no lv
hd6 hdisk1 rootvg 6144MB 1 yes
yes lv
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging01 hdisk1 rootvg 2048MB 0
no no lv
paging00 hdisk1 rootvg 2048MB 0
no no lv
hd6 hdisk1 rootvg 6144MB 1 yes
yes lv
[A]lpar1[/]# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
hd6 hdisk1 rootvg 6144MB 1 yes
yes lv
--
George
jthom...@yahoo.com
I dunno why but you can clean up a paging space by allocating 1 more
PP to it, and then delllocating it. Don't need multiple paging spaces
to do it.
GeorgeD
After two days the paging space usage went back to 60-68% usage.
I will have to increase the size of the paging space after all.
It's still a mystery why it reduced down to 2% usage initially.
--
George
Hajo Ehlers
In case no OS problem exist the paging page allocation depends on the
allocation type. Can be configured as system default, by environment
or by the program itself
Check http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/pag_overview.htm
Using paging space itself is not a problem imho ( 95% rule) . More the
amount of paging in/out. Use svmon to determine the processes which
are using paging page.
hth
Hajo
No Body
Didn't see in any of this where you mentioned how much of the 12GB of
RAM was currently in use. If you had free mem, deactivating the
pagespaces would simply shove the pages back into core memory...
-r
GeorgeD
GeorgeD
Thanks for the prompt about "shoving pages back into core memory".
What happened makes sense now.
Unfortunately I can't tell how much RAM was currently in use in the
original example.
Currently Comp is 33.2%, Noncomp=42.8%, Client=0.5%, And this shows
that currently
there is some free memory.
100-(33.2-42.8+0.5)=23.2% = 2.82 GB.
Paging size is 8GB, Usage is 25.8% = 2.06 GB.
And so if I were to do the reorg again, I expect that the paging space
would be freed up again
as there is enough free memory for all currently running processes,
and any which may be
not running and paged out.
(I won't do this of course because I don't have the time. But I needed
to reorg another LPAR so I
kept the figures on that.
This second LPAR also runs AIX5.2 TL10 on a p570. It has 4096 MB RAM
and 1 CPU.
Paging is defined on the rootvg as 3 mirrored LVs (hd6, paging00,
paging01) each 2GB
in size.
The paging space was 69% full.
I refactored this into a single pagings space - hd6 - of size 6144 MB
similar to my original method.
(chps -s 64 hd6; swapoff /dev/paging01; swapoff /dev/paging00; swapon /
dev/paging00; swapon /dev/paging01; swapoff /dev/hd6; swapon /dev/hd6
swapoff /dev/paging01, swapoff /dev/paging00)
At the end of the reorg the paging space was 32% used, but this is
slowly slowly increasing back towards 69%.
At the start of the reorg, Comp=66.4%, Noncomp=34.0%, Client=0.5%
(total=100.9 - must be rounding error)
And this shows that there was no free memory.
Also minperm=20%, maxperm=80%
So 69% of 6144MB = 4239MB of paging before
Comp memory = 66.4%*4095 = 2719MB before
32% of 6144MB = 1966MB of paging after
Because there is no available memory and there is more paging space
than Comp memory,
not all of the paging space can be freed up ("shoved back into
memory").
The lower limit of the resulting paging space is 4239-2719=1520MB (i.e
paging - comp)
And our result is 1966 MB (i.e. 32%).
The difference 1966-1520= 446MB can be accounted for by processes
which need to be
swapped out during relatively long reorg process, as there is clearly
more committed memory
than available real memory in this LPAR.
--
George
patrice
>
> - Afficher le texte des messages précédents -
Hi,
You are not in a normal situation regarding your memory statistics.
You mentionned that you have about 33% computing memory and about 25%
of your paging spaces occupied.
It sounds like your memory settings are not working in an optimal way.
There could be some differents ways to avoid such a behaviour.
Having 33% comp of memory used with 25% paging space used is a very
bad way to run.
If you post output of vmo -a command, I probably will be able to help
you.
Regards.
Patrice.