Go faster server
Most Linux systems ship with both a single-processor and a multiprocessor kernel: the single-processor version is simpler and does not contain special code to stop one processor ‘tripping over’ the other (more technically, it does not implement locks on various data structures in the kernel). Obviously, if you run a single-processor kernel on a multiprocessor machine, it will use only one of the processors. Newer processors such as Xeon support Hyper-Threading, which makes the machine run more effectively by treating the single processor as if it were two, but to exploit this you need to run an SMP kernel even on a single-processor machine. When you do this, you will see in the Top command twice as many processors as are actually fitted – for example, a dual-processor machine will show up with four processors.
3. Run the best binaries
Again, this applies particularly to Linux. When you run a binary, you have the choice of the one that came with your distribution, or of compiling one for yourself. Typically, the one that came with the distribution may have been compiled for a 386 machine, while you are probably running a 686 machine. Depending on the application, you may discover that recompiling the application for a 686 will produce better results – we have observed improvements with web servers and interpreters such as Perl, for example. Similarly, there may be architectural variants – for example, different SPARC processor versions on Sun, or Power processors on IBM machines – that a smart compiler can take advantage of. MySQLAB, the company responsible for the MySQL database server, quotes a 5 per cent improvement in performance by recompiling its database server for a specific version of the SPARC chip.
4. Inspect your hardware
You have added more memory and are running the right kernel, but things still seem slow. Check that the machine is working correctly – for example, make sure there are no disk problems and that there is no log file filling up with hardware errors. If you are experiencing network bandwidth problems, check that the network port is configured correctly to its optimum settings – if it is connected to a 100Mb switch, is the network interface running at 100Mb duplex?
Then you need to check the load on your machine. Start with the uptime command, which shows the ‘load average’. This is the number of processes the kernel has been trying to run. In principle, if this is more than twice the number of processors in the machine then you are running out of performance. So, on a single-processor machine a load average of one is fine, while a load average of three or four may see noticeable slowdown. At load averages of ten to 20 the machine is well overloaded, and if you get to a load average of 95 (a personal record) then just be impressed that the machine is still running at all!
After using uptime, try the top command, which shows processor usage and which processes are using what resources. Check for processes that consume large amounts of processor time or real memory by sorting top’s output in various ways. Also, if your Top command supports it, look at overall usage of real memory and processing time. Check whether large amounts of time are spent in ‘iowait’ – if so, then your machine is waiting for its disk drives, which is not good. The Top command is great for giving you a quick impression of what is happening, but to really get down to the nuts and bolts you need to look in more detail.
5. Inspect your file systems