Detecting disk bottlenecks
Posted: September 4th, 2008 | Author: TnT Admin | Filed under: Analyze | Tags: Bottleneck, Disk | No Comments »In most cases, applications can be tuned so that disk I/O does not cause any serious performance problems. However, performance problem may still persist even after application tuning. In this article, we will be addressing common disk bottlenecks and their tuning techniques.
Identifying whether the system has a problem with disk utilization first. Each system provides its own tools to identify disk usage (Windows: Perfmon, and UNIX: sar, vmstat, iostat utilities). For a start, identify whether the paging is an issue (look at disk-scan rates) and assess the overall utilization of your disks (e.g. Disk Transfers/sec on Windows, output from iostat –D on UNIX). It may be that the system has a problem independent of your application (e.g. unbalanced disks), and correcting this problem may resolve it.
If the disk analysis does not identify an obvious system problem that is causing the I/O overhead, you could try making a disk upgrade or a reconfiguration. This type of tuning can consist of any of the following:
- Upgrading to faster disks
- Adding more swap space to handle larger buffers
- Changing the disk to be striped (where files are striped across several disks, thus providing parallel I/O. e.g. with a RAID system)
- Running the data on raw partitions when this is shown to be faster.
- Distributing simultaneously accessed files across multiple disks to gain parallel I/O
- Using memory-mapped disks or files
You can never be sure if any particular disk is local to the user if you have applications running on many systems and unsure of the specification of the target system. There is significant possibility that the disk used by the application is a network-mounted disk. This doubles the variability in response times and throughput. A network disk is a shared resource, as is the network itself, so performance is hugely and unpredictably affected by other users and network load.
We will be touching on the common areas to of performance issue, namely (a) Disk I/O, (b) Clustering Files, (c) Cache File Systems, (d) Disk Fragmentations and (e) Disk Sweet Spots.
Disk I/O
Disk writes on the system can impact performance adversely as a whole. System swap files should be placed on a separate disk from their databases (recommended by database vendors). The impact of not doing so can decrease database throughput (and system activity). This performance decreases come from not splitting I/O of two disk-intensive applications (in this case, OS paging and database I/O).
Identifying that there is an I/O problem is usually fairly easy. The most basic symptom is that things take longer than expected, while at the same time the CPU is not at all heavily worked. The disk-monitoring utilities will also show there is a lot of work being done to the disks. At the system level, you should determine the average peak requirements on the disks. Your disks will have some statistics that are supplied by the vendor, including:
Average and peak transfer rates; normally in megabytes (MB) per seconds, e.g. 5MB/sec. Form this, you can calculate how long an 8K page takes to be transferred from disk, and for example, 5MB/sec is about 5K/ms, so an 8K page takes just under 2ms to transfer.
Average seek time; normally in milliseconds (ms). This is the time required for the disk head to move radially to the correct location on the disk.
Rotational speed; normally in revolutions per minutes (rpm), e.g. 7200rpm. From this, you can calculate the average rotational delay in moving the disk under the disk-head reader, i.e., the time taken for half a revolution. For example, for 7200rpm, one revolution takes 60,000ms (60 seconds) divided by 7200rpm, which is about 8.3 ms. So half a revolution takes just over 4ms, which is consequently the average rotational delay.
With the above list, you are able to calculate the total delay for a disk operation to load a random 8K page from disk with the following formula:
Using the examples given in the list, you have 10 + 4 + 2 = 16 ms to load a random 8K page (almost an order of magnitude slower than the raw disk throughput). This calculation gives you a worst–case scenario for the disk-transfer rates for your application, allowing you to determine if the system is up to the required performance. Note that if you are reading data stored sequentially in disk (as when reading a large file), the seek time and rotational delay are incurred less than once per 8K page loaded. Basically, these two times are incurred only at the beginning of opening the file and whenever the file is fragmented. But this calculation is confounded by other processes also executing I/O to the disk at the same time. This overhead is part of the reason why swap and other intensive I/O files should not be put on the same disk.
One mechanism for speeding up disk I/O is to stripe disks. Disk striping allows data from a particular file to be spread over several disks. Striping allows reads and writes to be performed in parallel across the disks without requiring any application changes. This can speed up disk I/O quite effectively. However, be aware that the seek and rotational overhead previously listed still applies, and there maybe no performance gain if you are making many small random reads.
Finally, note again that using remote disks adversely affects I/O performance. You should not be using remote disks mounted from the network with any I/O-intensive operations if you need good performance.
Clustering Files
Reading many files sequentially is faster if the files are clustered together on the disk, allowing the disk-head reader to flow from one file to the next. This clustering is best done in conjunction with defragmenting the disks. The overhead in finding the location of a file on the disk (detailed in the previous section) is also minimized for sequential reads if the files are clustered.
If you cannot specify clustering files at the disk level, you can still provide similar functionality by putting all the files together into one large file (as is done with the ZIP file systems). This is fine if all the files are read-only files or if there is just one file that is writable (you place that at the end). However, when there is more than one writable file, you need to manage the location of the internal files in your system as one or more grow. This becomes a problem and is not usually worth the effort. (If the files have a known bounded size, you can pad the files internally, thus regaining the single file efficiency.)
Cached File Systems (RAM Disks, tmpfs, cachefs)
Most OS provide the ability to map a file system into the system memory . This ability can speed up reads and writes to certain files to control the target environment. Typically, this technique has been used to speed up the reading and writing of temporary files. For example, some compilers (of languages in general, not specifically Java) generate many temporary files during compilation. If these files are created and written directly to the system memory, the speed of compilation is greatly increased. Similarly, if you have a set of external files that are needed by your application, it is possible to map these directly into the system memory, thus allowing their reads and writes to be sped up greatly.
But note that these types of file systems are not persistent and will be cleared (as with system memory) when it’s rebooted. If the system crashes, anything in a memory-mapped file system is lost. For this reason, these types of file systems are usually suitable only for temporary files or read-only versions of disk-based files (such as mapping a CD-ROM into a memory-resident file system).
Remember that you do not have the same degree of fine control over these file systems that you have over your application. A memory-mapped file system does not use memory resources as efficiently as working directly from your application. If you have direct control over the files you are reading and writing, it is usually better to optimize this within your application rather than outside it. A memory-mapped file system takes space directly from system memory. You should consider whether it would be better to let your application grow in memory instead of letting the file system take up that system memory. For multi-user applications, it is usually more efficient for the system to map shared files directly into memory, as a particular file then takes up just one memory location rather than duplicate in each process.
The creation of memory-mapped file systems is completely system-dependent, and there is no guarantee that it is available on any particular system (though most modern OS do support this feature). For Unix, look up for cachefs and tmpfs while for Windows, look out on how to setup a RAM disk (a portion of memory mapped to a logical disk drive). In a similar way, there are products available that pre-cache shared libraries (DLL) and even executables in memory which allows application to start quicker or loads the quicker, and so may not be much help in speeding up a running system.
But you can apply the technique of memory-mapping file systems directly and quite usefully for applications in which processes are frequently started. Copy the Java distribution and all class files (all JDK, application, and third-party class files) onto a memory-mapped file system and ensure that all executions and classloads take place from the file system. Since everything (executables, DLLs, class files, resources, etc.) is already in memory, the startup time is much faster. Because only the startup (and class loading) time is affected, this technique gives only a small boost to applications that are not frequently starting processes, but can be usefully applied if startup time is a problem.
Disk Fragmentation
When files are stored on disk, the bytes in the files are note necessarily stored contiguously: their storage depends on file size and contiguous space available on the disk. This non-contiguous storage is called fragmentation. Any particular file may have some chunks in one place, and a pointer to the next chunk that may be quite a distance away on the disk. Hard disks tend to get fragmented over time. This fragmentation delays both reads from files (including loading applications into computer memory on startup) and writes to files. This delay occurs because the disk header must wind on to the next chunk with each fragmentation.
For optimum performance on any system, it is ideal to periodically defragment the disk. This reunites files that have been split up, reducing disk heads time spent searching for data as the file-header locations have been identified, thus speeding up data access. However, defragmenting may not be effective on all systems.
Disk Sweet Spots
Most disks have a location from which data is transferred faster than from other locations. Usually, the closer the data is to the outside edge of the disk, the faster it can be read from the disk. Most hard disks rotate at constant angular speed. This means that the linear speed of the disk under a point is faster the farther away the point is from the center of the disk. Thus, data at the edge of the disk can be read from (and written to) at the faster possible rate commensurate with the maximum density of data storable on disk.
This location with faster transfer rates usually termed the disk sweet spot. Some (Commercial) utilities provide mapped access to the underlying disk and allow you to reorganize files to optimize access. On most server systems, the administrator has control over how logical partitions of the disk apply to the physical layout, and how to position files to the disk sweet spots. Experts for high-performance database system sometimes try to position the index tables of the database as close as possible to the disk sweet spot. These tables consist of relatively small amounts of data that affect the performance of the system in a disproportionately large way, so that any speed improvement in manipulating these tables is significant.
Note that some of the latest OS are beginning to include “awareness” of disk sweet spots, and attempt to move executables to sweet spots when defragmenting the disk. You may need to ensure that the defragmentation procedure does not disrupt your own use of the disk sweet spot.
(Source: Java Performance Tuning)
Leave a Reply