wohler@sapwdf.UUCP (Bill Wohler) (04/22/91)
swap space gurus:
with 128M of real memory and 208M of swap (and effective total of
336M of memory!) on a 530, i would not have expected to see "INIT:
swap space low", especially considering when the sum of the SIZE
column of "ps uax" is only 58M.
ps uax | awk '{sum += $5}
END {print sum}'
57876
researching this problem via info revealed the following numbers:
[wohler@aix3:175]% lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto
paging00 hdisk1 uservg 64MB 65 yes yes
hd6 hdisk0 rootvg 144MB 34 yes yes
---
208
[root@aix3:201]# vmstat
procs memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 0 24401 11756 0 0 0 0 2 0 117 55 37 1 1 96 0
24401 (avm) * 4096 = 96604k
11756 (fre) * 4096 = 47024k
--------
144628k
these numbers and info raise the following questions which info
couldn't answer. i'd be very thankful for any of your answers:
o what percentage of paging space free is considered to be a
low condition (ie. SIGDANGER's sent to processes)?
o is the total amount of available virtual space just the swap space,
or real memory plus swap space?
o what program is used to determine how much real memory the
system thinks it has?
o why is the swapper process so large?
o why is the total amount of available and free memory
displayed by vmstat not equal to 208 displayed by lsps?
o why is there such a discrepancy between the sum of the SIZE column
of ps and the avm field of vmstat?
in summary, do these numbers indicate a bug or a broken
configuration? why did the system indicate that we ran out of swap
space? what other tools do we have at our disposal?
--
--bw
-----
Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler>
Heidelberg Red Barons Ultimate Frisbee Teamslh@gibdo.engr.washington.edu () (04/23/91)
In article <2758@sapwdf.UUCP> Bill Wohler <wohler@sap-ag.de> writes: |swap space gurus: | | with 128M of real memory and 208M of swap (and effective total of | 336M of memory!) on a 530, i would not have expected to see "INIT: | swap space low", especially considering when the sum of the SIZE | column of "ps uax" is only 58M. | | ps uax | awk '{sum += $5} | END {print sum}' | 57876 | No swap space guru, but: I believe your virtual memory size is only as large as your swap space, so you really only have 208M of virtual memory. Also your awk thing will not always work, since the fields of ps can run together (not to say your sum probably isn't close enough)
hbergh@nl.oracle.com (Herbert van den Bergh) (04/23/91)
In article <2758@sapwdf.UUCP> Bill Wohler <wohler@sap-ag.de> writes: >swap space gurus: > > with 128M of real memory and 208M of swap (and effective total of > 336M of memory!) on a 530, i would not have expected to see "INIT: > swap space low", especially considering when the sum of the SIZE > column of "ps uax" is only 58M. > > ps uax | awk '{sum += $5} > END {print sum}' > 57876 You're adding the SZ column here. The Performance Monitoring and Tuning Guide descibes this column as: SZ The virtual size of the process. Specifically, SZ is the amount of paging space used by the data segment of the process, plus the amount of paging space used by the text segment of the process, expressed in kilobytes. The text segment of the process is generally resident on the filesystem, and thus does not use pages from paging space. *Note:* SZ values are subject to error in the first release of the system. Don't ask me what "first release" means. That's probably what we all have now. > > researching this problem via info revealed the following numbers: > >[wohler@aix3:175]% lsps -a >Page Space Physical Volume Volume Group Size %Used Active Auto >paging00 hdisk1 uservg 64MB 65 yes yes >hd6 hdisk0 rootvg 144MB 34 yes yes > --- > 208 This shows that (0.65*64M + 0.34*144M) = 41.60 + 48.96 = 90.56MB is in use. > >[root@aix3:201]# vmstat >procs memory page faults cpu >----- ----------- ------------------------ ------------ ----------- > r b avm fre re pi po fr sr cy in sy cs us sy id wa > 1 0 24401 11756 0 0 0 0 2 0 117 55 37 1 1 96 0 > > >24401 (avm) * 4096 = 96604k > >11756 (fre) * 4096 = 47024k > -------- > 144628k > From the same document: avm This data is not represented as a rate. It is the number of active virtual memory pages at the time of the interval sample. It represents the number of page space pages being consumed at that instant. fre This data is not represented as a rate. It is the number of real memory pages on the free list at the time of interval sample. So the avm column of vmstat is pretty close to the lsps percentage in use. > these numbers and info raise the following questions which info > couldn't answer. i'd be very thankful for any of your answers: > > o what percentage of paging space free is considered to be a > low condition (ie. SIGDANGER's sent to processes)? Maybe one of you IBM guys can answer this one? > o is the total amount of available virtual space just the swap space, > or real memory plus swap space? See the above description of avm: it stands for ACTIVE virtual memory. > o what program is used to determine how much real memory the > system thinks it has? One way of doing it is "lscfg -l mem" > o why is the swapper process so large? Because it shows the amount of paging space used by the kernel segment. The ps option u seems to have a bug that doubles this size for the swapper. "ps vg" shows a SIZE column for swapper that is half the size of the "ps aux" SZ column. > o why is the total amount of available and free memory > displayed by vmstat not equal to 208 displayed by lsps? See the description of avm and fre, they don't mean what you think they mean. > o why is there such a discrepancy between the sum of the SIZE column > of ps and the avm field of vmstat? See the *Note:* at the end of the SZ description. > in summary, do these numbers indicate a bug or a broken > configuration? why did the system indicate that we ran out of swap > space? what other tools do we have at our disposal? You can use 'sar -r' to see how many paging space pages are still free while your processes are running. >-- > --bw >----- >Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler> >Heidelberg Red Barons Ultimate Frisbee Team -- Herbert van den Bergh, Email: hbergh@oracle.nl, hbergh@oracle.com ORACLE Europe --