From: James Jackson (James.Jackson@MAIL.STATE.AR.US)
Date: Thu Nov 14 2002 - 10:18:49 EST
Holger,
Since numperm is less than maxperm, the VMM uses an algorithm that steals pages from both persistent (file) and non-persistent (process/working) pages based upon the repage rate for persistent pages; I presume this is why you're paging. Here's a couple of snippets from the 4.3.3 Peformance Management Guide that discusses this functionality, which appears to be unchanged in 5.1:
"Repaging - A page fault is considered to be either a new page fault or a repage fault. A new page fault occurs when there is no record of the page having been referenced recently. A repage fault occurs when a page that is known to have been referenced recently is referenced again, and is not found in memory because the page has been replaced (and perhaps written to disk) since it was last accessed.
When the percentage of real memory occupied by file pages is between minperm and maxperm, the VMM normally steals only file pages, but if the repaging rate for file pages is higher than the repaging rate for computational pages, computational pages are stolen as well."
I would guess that you're experiencing a high-level of repaging in your application; perhaps it's doing a lot of repeated table scans or field updates. Therefore, you may need to approach this from an application point-of-view and/or an AIX point-of-view. For simplicity's sake, I agree with others that have recommended that you reduce the values for minperm and maxperm incrementally, and observe the impact on page-ins and page-outs.
I note that you're consuming 3GB of paging space on a box with 6 GB of real memory. With numperm at 74%, that means your consuming ~25% of memory (~1.5GB) with working pages, for a total working load of ~4.5 GB. I suggest that if you set maxperm at 20% or less, then your proclivity to page should be greatly diminished, since your application need for working pages isn't overcommitting real memory.
Regards,
James Jackson
-----Original Message-----
From: Holger.VanKoll@SWISSCOM.COM [mailto:Holger.VanKoll@SWISSCOM.COM]
Sent: Thursday, November 14, 2002 3:16 AM
To: aix-l@Princeton.EDU
Subject: high paging
Hello,
why do I have so much paging on this box (3GB is used)
4 27 1146219 571 0 139 156 1657 2394 0 1969 9578 4332 20 7 0 73
4 18 1147233 613 0 162 111 3728 7464 0 2879 17201 8539 39 13 1 47
3 22 1147683 607 0 175 143 3149 10136 0 2513 20013 6676 37 12 1 51
2 21 1148753 592 0 136 143 3000 5212 0 2941 10902 8507 27 12 2 59
I have 71% memory used as filecache. So lrud should steal pages there, shouldn´t it?
I know that I have an io bottleneck; but much of this io goes to paging.
(0)root@sbe2622 359# /usr/samples/kernel/vmtune
vmtune: current values:
-p -P -r -R -f -F -N -W
minperm maxperm minpgahead maxpgahead minfree maxfree pd_npages maxrandwrt
314565 1258260 4 16 600 616 524288 0
-M -w -k -c -b -B -u -l -d
maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps
1258260 65536 16384 1 93 977 9 131072 1
-s -n -S -L -g -h
sync_release_ilock nokilluid v_pinshm lgpg_regions lgpg_size strict_maxperm
0 0 0 0 0 0
-t
maxclient
1257440
number of valid memory pages = 1572825 maxperm=80.0% of real memory
maximum pinable=80.0% of real memory minperm=20.0% of real memory
number of file memory pages = 1164847 numperm=74.1% of real memory
number of compressed memory pages = 0 compressed=0.0% of real memory
number of client memory pages = 38 numclient=0.0% of real memory
# of remote pgs sched-pageout = 0 maxclient=79.9% of real memory
I know the pgahead/minmaxfree parameters are not default, but I see no change when setting them to default.
Regards,
Holger
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:20 EDT