After sending my AIX memory tunings to the list, I received feedback from
members who had different results. So I revisited the tunings. I found that
MAXperm has an even greater influence than MINperm.
I now have settings I am comfortable with and have no intention to change. They
are shown below. I included a VMSTAT trace farther down to show my results.
Operationally, the system displays almost instant response to all queries,
sessions, etc. This is MUCH better than it worked when I began my tuning
experiments.
For those just tuning in:
AIX 4.3.2.0
ADSM 3.1.2.55
RS/6000 7025 F50
2 x 332 MHz CPUs
512 MB RAM
21.5 GB database, 87% utilized
4.4 GB recovery log
These are my current VMTUNE settings:
# vmtune
vmtune: current values:
-p -P -r -R -f -F -N -W
minperm maxperm minpgahead maxpgahead minfree maxfree pd_npages maxrandwrt
32765 78637 2 64 256 340 524288 0
-M -w -k -c -b -B -u -l
maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps
104851 8192 2048 1 93 305 9 131072 1
-s
sync_release_ilock
0
number of valid memory pages = 131063 maxperm=60.0% of real memory
maximum pinable=80.0% of real memory minperm=25.0% of real memory
number of file memory pages = 78202 numperm=59.7% of real memory
Non-default settings are minperm (-p), maxperm (-P), maxpgahead (-R), minfree
(-f), and maxfree (-F).
This is today's results from a 2-second vmstat trace. While this trace was
taken there were:
1 high data rate archive session running;
7 migrations from four disk pools to four tape libraries;
1 tape-to-tape backup to my copypool.
# vmstat 2 20
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
0 0 63361 378 0 1 0 271 18 0 29 231 39 3 7 65 25
2 6 63361 330 0 2 0 5022 22015 0 1975 2397 1791 16 44 0 40
2 7 63361 276 0 0 0 4287 11312 0 1712 1945 1540 12 35 0 53
1 8 63361 319 0 1 0 4605 12988 0 2008 1976 1510 16 38 0 46
0 8 63361 340 0 0 0 4393 13024 0 1615 1729 1270 16 35 0 49
2 6 63361 319 0 0 0 3591 9545 0 1757 1703 1326 17 29 0 54
0 6 63361 276 0 0 0 3605 10675 0 1745 1918 1363 18 32 0 51
0 5 63361 319 0 0 0 3583 13813 0 1696 1620 1334 16 32 0 52
3 5 63361 340 0 0 0 3752 12417 0 1796 1700 1395 16 32 0 52
0 6 63361 273 0 0 0 3727 12561 0 1535 1469 1272 16 34 0 50
3 6 63361 296 0 0 0 4302 14887 0 1650 1405 1182 18 32 0 50
0 7 63361 327 0 2 0 4235 17390 0 1602 1499 1245 16 33 0 51
3 5 63361 291 0 2 0 4366 11003 0 1799 1864 1455 13 38 0 49
0 6 63361 340 0 32 0 4013 11974 0 1693 1823 1481 18 33 0 48
2 5 63361 381 0 0 3 4758 13404 0 1712 1660 1250 12 38 0 49
1 6 63361 340 0 0 13 3991 10720 0 1551 1653 1263 18 31 0 52
2 6 63361 277 0 0 0 3719 12337 0 1816 1660 1236 16 32 0 52
0 6 63361 340 0 0 0 4031 16150 0 1481 1529 1217 18 34 0 49
0 5 63361 340 0 0 0 3624 11082 0 1826 2001 1522 16 34 0 49
1 6 63361 381 0 0 0 4708 13347 0 1447 1519 1199 19 36 0 46
Note that with all this I/O activity, and while freeing (fr) 3000-5000 pages in
each 2-second period, paging to/from disk (pi/po) stays at or near zero and free
memory (fre) never bottoms out.
Tab
