These three commands should provide a good snapshot of what's going on system-wide right about now:
Code:
free -m
ps aux
vmstat 1 30
(the vmstat command will run for 30 seconds, then exit)
Post the output here and everyone will opine on it.
From a prioritization standpoint, getting your swap I/O under control is probably #1. That slows everything down.
Next, your disk I/O is rather high. Figuring out whether it is reading or writing is key, as is figuring out exactly what is doing the reading or writing. The vmstat command will help a bit with this, but iotop is sometimes useful. (Most of the time, though, it doesn't tell me anything I don't already know. Whoop-de-flippin'-doo, mysqld is doing most of the I/O on my database server...)
CPU is CPU. There are lots of them in each host, and the most you can use at one time are four. The kicker with CPU is that you can only crunch data so fast, so if you're using a lot of CPU, your site is going to be slow.
If you can split up your tasks between multiple servers such that they're all sharing the I/O burden equally, life can be pretty good. I usually end up having a set of database servers, a set of web servers, and then some number of servers for other services (solr, memcached, postfix, munin/nagios/etc, SVN, ...). Make a block diagram of your operations, with lines denoting dependency, and little symbols indicating "does a lot of IO", "uses CPU like a drunken squirrel", "needs 4 GB of RAM", etc. You don't need to deploy your system such that you have no more than one block per server, but since each block should be able to talk to the other blocks it depends on over IP, you
could.
(Beware the dreaded Distributed Single Point of Failure.)
_________________
Code:
/* TODO: need to add signature to posts */