linux-delhi.com Blog of a Linux Geek who likes Delhi

Check whether the network is at Full Duplex and at the rated capacity
Its not un-common for Gigabit network cards to be running at 100baseT/Half duplex or 100baseT/Full instead of 1000baseT/Full due to minor auto-negotiation failures.
ethtool is your friend to determine the current network speed possible on a network interface card(NIC).

Kernel Version

Is it greater than 2.6.17. In that case the kernel would auto-tune itself and you don't need to mess around with the various options available.

Here is an excellent explanation of what needs to be tuned for good network performance.

1. Mount options: use noatime

Most Linux server machines can do without last access time modified for every file and each directory which is being read. So I'll just go ahead and re-quote for the nth time what Linux Kernel developer Ingor Molar has to say to emphasize the point.
<Quote>
i cannot over-emphasise how much of a deal it is in practice. Atime
updates are by far the biggest IO performance deficiency that Linux has
today. Getting rid of atime updates would give us more everyday Linux
performance than all the pagecache speedups of the past 10 years,
_combined_.
<Quote/>

You can simply remount your filesystems without rebooting your machine using.
As an example:-
/bin/mount -t ext3 -o noatime ext3 /dev/sda5 /

And don't forget to modify corresponding lines in your /etc/fstab
/dev/sda5 / ext3 noatime 1 1

2. Use tmpfs
Speedup heavy read-write IO for temporary data stores by by using memory instead of disk.

3. On systems not constrained for memory reduce swappiness of the Linux machine
/bin/echo "10" > /proc/sys/vm/swappiness

4. Set blockdev readahead to a reasonable value to improve read performance
/sbin/blockdev --setra 131072 /dev/sda

The default readahead value is too small.

Although reading and writing to files is fast in Linux with aggressive readahead and caching, it can still slow down applications that make extensive use of ondisk temporary files. As an example MySQL which can do a lot of on disk temporary tables if the temporary tables need to have a large varchar, text or binary column.
It makes sense to mount an in-memory filesystem on the MySQL's tmpdir usually /tmp to ensure that your on-disk temporary tables are rapidly written to and read from memory to return query output fast by avoiding expensive disk IO. Similarly a lot of different web applications can derive a lot of benefit by writing temporary data to an in-memory filesystem as opposed to the disk.
The two choices ramdisk and tmpfs
Linux Kernel loads up 16 Ramdisks of 16 MB each at bootup time. They don't occupy any memory space at initialization. Ramdisks allocate memory when they are put to use by formatting them as ext2 or some other non-journaling filesystem. ( no not ext3, there is no use of journaling for an filesystem that is transient ) Once allocated the memory can't be returned from a ramdisk to the operating system. Ramdisks suffer from another limitation that its size can't be dynamically increased.
tmpfs on the other hand doesn't need to be formatted as another disk filesystem. Its can be dynamically resized. Un-utilized memory can be used by the operating system. The only downside is that tmpfs can also use Virtual Memory and its contents can be swapped out causing disk IO that we seek to avoid by using tmpfs. However swappiness should be minimized on a mission critical server anyway by tuning the /proc/sys/vm/swappiness value at boot time.

As an example of how to use tmpfs
/bin/mount -t tmpfs -o size=1G,nr_inodes=10k,mode=0775,noatime,nodiratime tmpfs /tmp

to dynamically increase its size
/bin/mount -t tmpfs -o size=2G,nr_inodes=20k,mode=0775,noatime,nodiratime,remount tmpfs /tmp

Tuning the swappiness
/bin/echo "1" > /proc/sys/vm/swappiness

These need to be added to /etc/rc.local to make the settings persistent across reboots.