DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Tuning I/O resources

Overcoming performance limitations of hard disks

One area where you are likely to experience performance limitations is with I/O from and to hard disks. These are heavily used on most systems, and accessing data on them is much slower than is the case with main memory. The time taken to access main memory is typically many thousands of times less than that taken to access data on disk. The solution is to try to arrange for the data that you want to be in a memory cache when you need it, not on disk. The cache may be one maintained by the operating system, though many applications such as databases manage their own caching strategies in user space. The situation is helped further by modern disks and disk controllers which implement cache memory in hardware.

``Increasing disk I/O throughput by increasing the buffer cache size'' describes how you can tune the buffer caching provided for access through the interface to block devices such as hard disks.

``Viewing namei cache activity'' describes how to tune the namei cache. This is the cache that the system maintains to avoid disk access when mapping filenames to inode numbers.

Not all activity on disk involves access to filesystems. Examples are swapping and paging to swap space, and the use of raw disk partitions by many database management systems. It is worth examining disk transfer request activity to discover how busy a system's disks are at the lowest level. ``Viewing disk and other block I/O activity'' describes how you can monitor the activity of block I/O in a system not only for block-structured media such as hard disk, CD-ROM, floppy and floptical disks, but also for SCSI tape drives.

Curing a disk I/O bottleneck caused by limited bandwidth


Comparison of I/O activity allows you to see if activity between different disks is unbalanced. In itself, this is not a problem unless the bandwidth of a particular disk is limiting throughput. ``Curing a disk I/O bottleneck caused by limited bandwidth'' shows a system where a disk I/O bottleneck is cured by the addition of an extra disk or a caching disk controller. Adding an extra disk is likely to be successful unless the bandwidth limitation occurs elsewhere, for example, in the disk controller. Adding a caching controller is likely to succeed where a disk is having difficulty coping with peak demand. A write-back cache should be backed up by a UPS to guard against mains power failure and the consequent data loss that would occur.

Balancing activity between disks may sometimes be achieved by simply moving a filesystem between two disks. A disk I/O bottleneck may occur if applications software and a user filesystem coexist on the same disk. This may lead to large access times as the disk heads are consistently sweeping across the entire disk. One solution is to move the applications software to other disk(s). The documentation for the applications may provide guidelines for this.

It is often unwise to move software or user filesystems onto the hard disk containing the root filesystem. Depending on how you use the system, this can be one of the most heavily-used disks.

A common source of disk bottlenecks on relational database servers occurs when the journal logs (used if the system has to recover from a crash) share the same disk as database tables and indexes. The journal logs are constantly updated and the disks containing them are usually the busiest on the system. The journal logs are also written sequentially so keeping them on separate disks reduces seek time. ``Curing a disk I/O bottleneck caused by unbalanced disk I/O activity'' shows how a disk dedicated for use by the journal logs might be added to a system in order to remove a bottleneck.

Another method for rebalancing disk activity is to create a virtual disk from several existing disks. See ``Administering virtual disks'' for more information. If a striped virtual disk is configured, this can increase disk throughput by spreading I/O activity evenly across the physical disks. Although the performance of disks containing a database journal log would benefit from striping, it is not advisable to stripe other filesystems across the same disks. Similarly, if there are several journal logs, these should be kept on physically separate disks.

If you have configured one or more virtual disks on your system, see ``Tuning virtual disk performance'' for more information about how to tune them.

Curing a disk I/O bottleneck caused by unbalanced disk I/O activity



Next topic: Tuning virtual disk performance
Previous topic: Filesystem factors affecting disk performance

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003