Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!mcsun!hp4nl!orcenl!hbergh From: hbergh@nl.oracle.com (Herbert van den Bergh) Newsgroups: comp.unix.aix Subject: Re: mathematics of swap space Message-ID: <1344@nlsun1.oracle.nl> Date: 23 Apr 91 12:47:35 GMT References: <2758@sapwdf.UUCP> Sender: Herbert van den Bergh Reply-To: hbergh@oracle.nl (Herbert van den Bergh) Organization: Oracle Europe, De Meern, The Netherlands Lines: 119 In article <2758@sapwdf.UUCP> Bill Wohler 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 >Heidelberg Red Barons Ultimate Frisbee Team -- Herbert van den Bergh, Email: hbergh@oracle.nl, hbergh@oracle.com ORACLE Europe --