Page faults occure when a page is demanded but has not been read into memory. So this is not a problem at 1st hand but often just a usual way when things are read from disk into memory and I do not mean from paging space.

For scan rate and freeing memory I wrote something here:
Scan Rates

It seems your box has running a CPU intensive java application and is not really short on memory. Nothing to worry about as long as the value of kthreads in the r-column (runqueue) is not bigger than the number of CPUs. Even though I saw boxes with higher numbers there and the application ran smooth though. It seems that current VMM setting just make it scanning memory where there is still enough available.
Severe memory problems usually are indicated when the pi/po columns of vmstat for example (which stand for pagingspaceins and pagingspaceouts) show any numbers. Usually you just try out some VMM settings and get over this. If not you might need more memory, which seems not the case with your box. Other tools show pi and po and mean normal pagein and pageout. Your topas output shows both, pageins/pageouts and pgspins/pgspouts. The later two regarding Paging Space are the problematic ones.

As it seems somebody has already tuned a bit on the box since

Code:

                 20.0 maxperm percentage

Does not have the default value anymore. Today people usually don't set this anymore but people set lru_file_repage=0 and let maxperm and maxclient on 80-90%. minperm is often reduced to 5%. So LRU decides with those thresholds when to clean up or not. You could check out if this is more pleasant for you and reduces sr/fr.

There is also some things here, that might not be noticable but can be tuned with ioo:

Code:

                 5114 pending disk I/Os blocked with no pbuf
               151149 paging space I/Os blocked with no psbuf
                 2484 filesystem I/Os blocked with no fsbuf
                41094 client filesystem I/Os blocked with no fsbuf
                 8101 external pager filesystem I/Os blocked with no fsbuf

If those values don't increase fast/in big amounts, you might not want to worry about them - best monitor them to decide if you tune them with ioo or not.

If you decide to use vmo to try out what I suggested, you could do the following:

Code:

vmo -p -o lru_file_repage=0
vmo -p -o minperm%=5
vmo -p -o lru_poll_interval=10

With vmo -x or -L you can always check back which command needs a reboot etc. and what the default values are and what the current are. So maybe write them down somewhere in case you want to go back. These 3 need no reboot. It can take some minutes until LRUD has settled memory.

And here some interessting links:

http://www.filibeto.org/unix/aix/lib...cement-vmm.pdf
Jaqui's AIX Performance and Security Blog
... as well as the Performance Tuning Redbooks from IBM.

Oh and please give note when you try out something and tell us how it went, thanks