Performance Tuning and Monitoring, Part 1


We generally use an OS in its native configuration—i.e., without bothering much about how the system will behave or respond in the current load situation. The overall load may vary from time to time, depending on the situation. So we need to continually monitor and tune our systems in the same manner like we change our car gears—depending upon the road and traffic conditions. Simply put, the objective of this series is to make Linux work more efficiently.

Performance tuning requires that you should have a sound knowledge of computer hardware—how the various computer components talk to each other, in addition to the various components of the operating system. Collecting relevant data about a problem and analysing it is very important in successful performance tuning.

Let’s start with some of the data gathering tools that can be used on Linux machines with kernel 2.6.x. The data gathered by these tools will then be used to analyse the problem, which will eventually lead to the solution.

Start with ‘Beater Box’

Never consider performance tuning as some black art, with which you can give certain commands and your machine will start behaving just as you wanted it to. And never directly use all these labs/tools on a production server. Instead spare yourself a ‘crash test dummy’, also referred to as ‘Beater Box’. Test several or all of the changes on that system to see the effects.

Collecting hardware configuration data

There are several tools that you can use to collect important information about your machine hardware. This is very important in efficient performance tuning.


vmstat provides information about processes, memory, paging, block I/O, traps, and CPU activity. It displays either average data or actual samples. You can enable the sampling mode when you additionally provide a sampling frequency and a sampling duration to vmstat.

The following command will display my machine’s virtual memory report after a delay of two seconds, for four times.

# vmstat 2 4

Take a look at Figure 1 for the output of this command. Note that the first line of this report shows the averages since your last reboot. So there’s no need to panic and you should ignore it.

Figure 1: A typical vmstat output
Figure 1: A typical vmstat output

vmstat displays the following statistics:

  1. Process (procs) section
    • r – number of processes waiting for runtime
    • b – number of processes in uninterruptible sleep
  2. Memory section
    • swpd – amount of virtual memory used (KB)
    • free – amount of idle memory (KB)
    • buff – amount of memory used as buffers (KB)
    • cache – amount of memory used as cache (KB)
  3. Swap section
    • si – amount of memory swapped from the disk (KB per second)
    • so – Amount of memory swapped to the disk (KB per second)
  4. IO section
    • bi – blocks sent to a block device (blocks/s)
    • bo – blocks received from a block device (blocks/s)
  5. System section
    • in – number of interrupts per second, including the clock
    • cs – number of context switches per second
  6. CPU section
    • us – time spent running non-kernel code (user time, including nice time)
    • sy – time spent running kernel code (system time)
    • id – time spent idle


  1. Where is the tuning part – please tell us how to tune following item

    1. Disk I/O Writes
    2. Tuning Network waittime/connection/max_number_of_connection
    3. CPU Tuning per process/maximum/minimum
    4. Tuning swap for process and etc


Please enter your comment!
Please enter your name here