I'm not sure I would concur. If the system was getting blocked while waiting for paging to occur, I would expect that to show up in %wa (I/O Wait time). Having said that, more RAM certainly couldn't hurt, but I don't think that's the immediate bottleneck.
–
ktowerMay 21 '10 at 20:40

True, it would require more than just this snapshot to be certain. But that memory is overallocated by 180MB is a fact.
–
Ignacio Vazquez-AbramsMay 21 '10 at 20:45

You running Xen VMs? That might explain the RAM difference. The low IO wait indicates that it's not swapping and paging like crazy. My assumption is you have a fairly heavy hitting user space application? Perhaps a collection of VMs?

The somewhat low buffer usage indicates that you have user space apps eating up your RAM and it's not all going towards internal kernel structures (which Linux will do rather than leave it idle).

Either way, more RAM first. If you're still seeing usage like this (high user), then updating might help.

Notice I said might help. You'll get a benefit with a faster clock rate and better L2 caching, but unless your applications take advantage of multiple cores, you're probably going to be in the same boat (though, a little bit of a bigger one).

Blah blah blah, this is about as accurate as anyone can get with a single point-in-time top snapshot. For all we know, some dumb user decided to calculate primes at the same time you ran top.

Edit: But the high swap usage does indicate it's choked for RAM. You need RAM. Then attack the CPU.