hIOmon SSD Performance Monitor - Understanding desktop usage patterns.

[overthere]

Continuing from my prior post #233 in regards to Ao1's post #222:

Assumptions:
• Performance in these stages is down to the OS and RAM. Nothing is occurring on the device.
• The system cache IOP miss counts are page faults from RAM, which then require a re-read from the file system.
• Most of the Read/ Write FastIOPcounts are done in cache and when this happens there are independent of the device speed. If I look at the results from post #48 it is likely that the 87.6% FastIOPcounts with HDD were predominantly achieved by cache. The SSD managed 100% because the speed of the SSD was such that it could satisfy non cached read IOP counts in less than a millisecond. [Edit] So it seems activities from 1 to 5 are designed to mitigate the slow speed impact of a HDD. I wonder if the file system driver/ cache manager could be better optimised for SSD. (?)

Performance throughout the TechNet diagram/scenario number one (i.e., system file cache "read hit") is essentially related to that of the OS and RAM, with the actual device not being a factor within this scenario.

Performance in the case of the TechNet diagram/scenario number two (i.e., system file cache "read miss") is also essentially related to that of the OS and RAM, with the device only becoming a factor when a system file cache read miss actually occurs (since the data for the read I/O operation must then be retrieved from the actual storage media).

The set of "SystemCache" summary I/O operation performance metrics collected by the hIOmon software reflects those I/O operations that explicitly requested the use of the "system file cache"; moreover, these I/O operations are handled by means of an expedited path through the OS I/O stack.

The hIOmon software considers an I/O operation to be a "system cache hit" when the I/O operation, as observed by the hIOmon I/O Monitor, was successfully performed using the "system file cache" by explicit request and which completed within less than one millisecond.

Similarly, "SystemCache" I/O operations that completed within one or more milliseconds are regarded to be "system cache misses" and are considered to have incurred an I/O operation directed to the corresponding actual device.

It is also imporant to note that:

1. Those I/O operations that are identified by the hIOmon I/O Monitor as "Fast I/O operations" include both the "System Cache Hit" I/O operations (as described above) as well as those I/O operations that did not explicitly request the use of the "system file cache" but which nevertheless completed in under one millisecond.
   
   
2. "Fast I/O operations" that do not explicitly request the use of the "system file cache" can nevertheless be satisfied by the system file cache under the direction of the OS. That is, there can be I/O operations that complete in less than one millisecond (and so are considered to be "Fast" I/O operations) that the OS satisfied by using the system file cache even though these I/O operations did not explicitly request the use of the system file cache.
   
   
3. "Fast I/O operations" also include those I/O operations for which there was no system file cache involvement but which neverthesless completed in less than one millisecond; these I/O operations can include physical volume and/or physical device I/O operations.

In regards to the FastIOPcount metric values shown in post #48, I am not sure whether the metrics shown were collected by hIOmon at the file level (i.e., logical disk level) or at the physical volume or physical device level.

In any case, HDD physical volume (or physical device) I/O operations that are observed by hIOmon to be "Fast I/O operations" are often the result of caching further down the I/O stack (e.g., a cache upon a RAID controller card, a cache upon the device itself, etc.). SSDs are, of course, another matter given their inherent fast read access times as Ao1 mentioned.

\Device\HarddiskVolume3 is when data actually gets read and written to the device. I assume stage 7 - Disk Driver.

Assumptions:
• This is when the speed of the device counts, however when this actually occurs is typically “after the event”. The speed of the device only therefor counts if it is a direct read/ write that bypasses the cache manager. (Assuming no further load when the read/ write occurs)

The I/O operation performance metrics collected by hIOmon at either the physical volume level (e.g., \Device\HarddiskVolume3) or the physical device level within the OS do reflect data that is actually transferred with the storage media proper.

This is where the performance characteristics of the storage media (along with the other components along the I/O operation path, e.g., the transport interface type, HBA, etc.) especially come into play and can have a significant impact upon the overall performance of the I/O operation.

Please note that the "speed" of the device (and the other elements down the path to the device) is a factor not only in the case of "system file cache misses" (i.e., how quickly the data can be retrieved to satisfy a file I/O operation that encounters the system file cache miss), but can also be a factor in anticipatory pre-fetching by the OS into the system file cache.

That is, the "faster" the OS can pre-fetch the data from the device, then presumably the more likely that the data will already be resident within the system file cache when a subsequent file read I/O operation is performed to retrieve this pre-fetched data. Of course, there are also a number of other factors to be considered in such a scenario (e.g., the extent to which the file I/O operations are sequential read I/O operations, the concurrent I/O activity of other, perhaps competing processes/applications, etc.) along with a slew of other caching, system, and resource issues.

E: is a summary of all activity within stages 1 and 7

Assumptions:
• This is showing all activity be it in cache or on the device.

The hIOmon software can be configured to collect "summary" I/O operation performance metrics upon an individual device basis.

In the case of a "device summary" for a logical drive/disk (e.g., E:), the summarized I/O operation performance metrics represent the sum of the performance metrics for all of the files being monitored by the hIOmon I/O Monitor for the specified logical disk.

That is, the "Device Summary" for the logical disk represents the overall aggregate of all summarized I/O operation metrics for all files (and only those files) that were being monitored by the hIOmon I/O Monitor and which reside upon the respective device.

Also please note that the "Device Summary" reflects cumulative metrics that have been collected by the hIOmon I/O Monitor since it began (or re-started) monitoring I/O operations for the respective device.

In contrast, the summary I/O operation performance metrics that are collected by the hIOmon I/O Monitor upon a periodic basis for files reflect only those I/O operations that were observed by the hIOmon I/O Monitor during the duration of the corresponding summary time period (e.g., if the summary metrics are being collected upon a "one minute" periodic basis, then the summary metrics reflect only those I/O operations that were observed during the respective one-minute period).

In any case, the "Device Summary" metrics for a logical device include both "SystemCache" and "PhyDev" I/O operation performance metrics for those monitored files associated with the logical device.

\Device\HarddiskVolume3:\<DASD>\VMMFrom previous posts this has been explained as “system flags associated with the I/O operation indicate involvement by the system “Virtual Memory Manager (VMM)”.

Assumptions:
• Entry 21 is why the re-paste appeared to be instantaneous. It was copying data from the VMM to the file system driver. The actual read/ write on the device occurred a minute later.

Entry 21 within the hIOmon metrics table is certainly a key entry. It shows not only the data read from the device (Read Data Xfer), including that for the "E:\Test File\Test.avi" file to be copied (some of which was copied into the system file cache) but also the data written to the device from the system file cache (Write Data Xfer), including both times the file was copied.

In addition, entries 33 and 36 show the copied file being written to the system file cache (q.v., WriteSystemCacheIOPcount and WriteDataXferSystemCacheHit) and written to the device (PhyDevWriteDataXfer).