First, 4GiB of memory for serious database applications is considered tiny by today's standards so the first thing that I would consider doing is increasing the memory. This will probably have another desired effect in that the database buffers in shared memory can then be increased which may reduce your i/o. Essentially the only way to give the users more memory is to reduce some of the kernel data -- notably the buffer cache. You have to play a balancing act between shared memory needed by the database, memory needed by the applications, and memory needed by the kernel. If your dbc_max_pct is at the default value of 50%, it should be drastically reduced -- especially if you are using raw devices --- but you still need some buffer cache for ordinary i/o.
Make certain that you are not swapping to any significanrt degree when under heavy load because this will easily impose a 100x performance hit.
Finally, you may tune this thing, add more memory, processors, and i/o paths and still have a dog because of inefficient or poorly written software. Database applications are notorious for this. If I can assume that you are not swapping then you need to ask yourself this: If I make my machine 2X as fast will it still be a dog? If so, you need to take an extremely hard look at your code because a 2X performance increase is difficult to achieve whereas a 10X increase can often be achieved with better algorithms. With databses, one index may fix a huge chunk of your performance problem.
If it ain't broke, I can fix that.
