Nope. I think (from what I have seen), that there is an SQL-statement runing on a table which has not been indexed and might therefor be eating more cpu-time. Looking at some scripts that just perform the same action over a thousand times in a script might be the cause of your problem now.
Our DBA and I have often seen users run awfull SQL statements which cause this problem.
It might be nice for you to find out the real bottleneck in her performing : sar 2 20 . You can now see if it's WIO/ USR or SYS. Most off all it will also be WIO. Still upgrading memory should not matter.
Aargh, will deep into it a bit more. Please perform a
"swapinfo -at"
and paste the output here. Also the output of "sar 5 20" would be nice. Please let me know the total amount of physical memory and created swap. Also let me know on what disk you configured swap. please give me a "sar -d 5 20" output of this disk.