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)

Usually, this happens when the the disk is very busy such as copying of large amount of files out copying multiple files, etc. We must first understand that whatever monitoring data Controller is displaying for Windows is based on Windows Perfmon. You can refer to the article titled, “How does the monitoring work in LoadRunner?” if you need some explanation. This is actually by design of the Windows OS.

The behavior can occur because the OS uses overlapping input/output operations for multiple outstanding requests. The disk performance counters time the responses by using a 100 nanosecond precision counter, and then report the cumulative statistics for a given sample time. This sample time could go over 100 percent if, for example, you have 10 requests that completed in 2 milliseconds each in a 10 millisecond sampling interval. If you have multiple disks in a Raid arrangement, the overlapped input/output happens because the operating system can read and write to multiple disks, and this could show values that are higher than 100 percent for this counter.

(Source: Microsoft Help and Support)

There is no quick fix to this as of this writing and the most accurate way to determine disk utilization is to use % Idle Time in the below formula:

100% – % Idle Time = Actual % Disk Utilization

To monitor disk activity, we can use this counter. When the measurement goes above 25 disk I/Os per second then you’ve got poor response time for your disk (which may well translate to a potential bottleneck. To further uncover the root cause we use the next mentioned counter.

Physical Disk(instance)\% Idle Time

This counter measures the percent time that your hard disk is idle during the measurement interval, and if you see this counter fall below 20% then you’ve likely got read/write requests queuing up for your disk which is unable to service these requests in a timely fashion. In this case it’s time to upgrade your hardware to use faster disks or scale out your application to better handle the load. Why not use Physical Disk(instance)\% Disk Time instead? Well, we will cover this in details in future post.

(Source: Mitch Tulloch, Windows Networking)

Often when you add the % Disk Read Time and % Disk Write Time counters together, they do not add up to % Disk Time. Furthermore, the % Disk Time counters are capped in the System Monitor at 100 percent because it would be confusing to report disk utilization greater than 100 percent. This occurs because the % Disk Time counters do not actually measure disk utilization. The Explain text that implies that they do represent disk utilization is very misleading.

What the % Disk Time counters actually do measure is a little complicated to explain but Mark provided a detail explanation in the following paragraphs which required your attention to read through.

The %Disk Time counter is not measured directly instead it is a value derived by the diskperf filter driver that provides disk performance statistics. diskperf is a layer of software sitting in the disk driver stack. As I/O Request packets (IRPs) pass through this layer, diskperf keeps track of the time I/O’s start and the time they finish. On the way to the device, diskperf records a timestamp for the IRP. On the way back from the device, the completion time is recorded. The difference is the duration of the I/O request.

Averaged over the collection interval, this becomes the Avg. Disk sec/Transfer, a direct measure of disk response time from the point of view of the device driver. diskperf also maintains byte counts and separate counters for reads and writes, at both the Logical and Physical Disk level. (This allows Avg. Disk sec/Transfer to be broken out into reads and writes.)

The Avg. Disk sec/Transfer measurement reported is based on the complete roundtrip time of a request. It is a direct measure of disk response time- which means it includes queue time. Queue time is the time spent waiting for the device because it is busy with another request or waiting for the SCSI bus to the device because it is busy.

% Disk Time is a value derived by diskperf from the sum of all IRP roundtrip times (Avg.Disk sec/Transfer) multiplied by Disk Transfers/sec, and divided by duration, or essentially:

% Disk Time = Avg Disk sec/Transfer * Disk Transfers/sec

which is a calculation (subject to capping when it exceeds 100 percent).

Because the Avg. Disk sec/Transfer that diskperf measures includes disk queuing, % Disk Time can grow greater than 100 percent if there is significant disk queuing (at either the Physical or Logical Disk level). The Explain text in the official documentation suggests that this product of Avg. Disk sec/Transfer and Disk Transfers/sec measures % Disk busy. If (and this a big “if”) the IRP roundtrip time represented only service time, then the % Disk Time calculation would correspond to disk utilization. But Avg. Disk sec/Transfer includes queue time, so the formula used actually calculates something entirely different.

(Source: O’Reilly Network)