Quantcast
Channel: VMware Communities : All Content - VMware I/O Analyzer
Viewing all articles
Browse latest Browse all 403

IO Analyzer and vmdk IO alignment

$
0
0

I was scratching around with I/O Analyzer v 1.0 and noticed that the IOmeter profiles that you provide appear to align on sector boundaries (i.e. 512b). I believe this is the default setting with IOmeter if it is not specified in your icf file. For example from 32k_50read_100rand.icf:

 

'ACCESS SPECIFICATIONS =========================================================
'Access specification name,default assignment        32k; 50% Read; 100% Random, NONE
'size,% of size,% reads,% random,delay,burst,align,reply        32768,100,50,100,0,1,0,0
'END access specifications
align = 0 so sector boundaries are used. The problem with this is that if you use a raw device for IOmeter disk, you will end up with non-aligned IO. As it is critically important to maintain alignment throughout the storage stack and especially with vmdk, I believe this needs to be addressed.
To verify non-aligned IO is generated by I/O Analyzer, I used a modified .icf and traced the vmdks under test with vscsiStats. Then I parsed the trace output to examine the LBA for each I/O produced during a 120 second run (see script below).
For example, to trace and logchannellogger the trace:
esx# vscsiStats -t -s -w 8385874 -i 8313
esx# vscsiStats -t -s -w 8385874 -i 8313vscsiStats: Starting Vscsi stats collection for worldGroup 8385874, handleID 8313vscsiStats: Starting Vscsi cmd tracing for worldGroup 8385874, handleID 8313<vscsiStats-traceChannel>vscsi_cmd_trace_8385874_8313</vscsiStats-traceChannel>Success.esx# logchannellogger vscsi_cmd_trace_8385874_8313 /vmfs/volumes/vmhost-Local/aligned.trc &<I/O Analyzer 4096b aligned run here>
esx# vscsiStats -x
esx# vscsiStats -e /vmfs/volumes/vmhost-Local/aligned.trc > aligned.txt

 

Here are the results of the two runs.

 

First run is non-aligned using a modified version of the default icf's provided (align=0):

 

 

'ACCESS SPECIFICATIONS =========================================================

'Access specification name,default assignment

        12k; 33% Read; 100% Random, NONE

'size,% of size,% reads,% random,delay,burst,align,reply

        12288,100,33,100,0,1,0,0

'END access specifications

 

 

Alignment check:

 

 

[root@vmtst-ads-control traces]# cat nonaligned.iometer.txt | perl ../parse-trace.pl

Total IOs: 718549, 4K aligned: 89815, not 4K aligned: 628734

 

 

Second run is aligned (4K/4096b) using a modified version of the default icf's provided (but with align=4096):

 

 

 

'ACCESS SPECIFICATIONS =========================================================

'Access specification name,default assignment

        12k; 33% Read; 100% Random, NONE

'size,% of size,% reads,% random,delay,burst,align,reply

        12288,100,33,100,0,1,4096,0

'END access specifications

 

 

Alignment check:

 

[root@vmtst-ads-control traces]# cat aligned.iometer.txt | perl ../parse-trace.pl

Total IOs: 828443, 4K aligned: 828443, not 4K aligned: 0

 

 

 

Summary of results (sample size of 1 each but no reason to test more samples in this case):

 

 

RunTotal IOs4K aligned IOsnon 4K aligned IOs% 4K aligned
default_IOAnalyzer_alignment71854989815628734 12.49%
4096b_IOAnalyzer_alignment8284438284430100%

 

 

The 12.49% result makes sense because one would expect with random I/O and 512b alignment, 1 out of every 8 IOs would happened to be aligned on a 4K boundary (i.e. 4096/512 = 8 => 1/8 = 0.125 => 12.5%). You can even see we got slightly higher IO out of the aligned case although this could be attributable to something else (warm cache), but not atypical when dealing with misaligned performance results.

 

I checked all of the .icf files provided with IO Analyzer v 1.0 and they all have align=0 in the access specifications.

 

Here is my simple script to check alignment:

 

 

#!/usr/bin/perl
use strict;
# Simple script to check 4K alignment of vscsiStats trace output
#
# Example of how to collect vscsiStats trace output:
# vscsiStats -t -s -w 8385874 -i 8313
# vscsiStats -t -s -w 8385874 -i 8313
#<vscsiStats-traceChannel>vscsi_cmd_trace_8385874_8313</vscsiStats-traceChannel>
# logchannellogger vscsi_cmd_trace_8385874_8313 /vmfs/volumes/vmhost-Local/io.trc &
#<do the IO you want to trace here>
# vscsiStats -x
# vscsiStats -e /vmfs/volumes/vmhost-Local/io.trc > io.txt
# cat io.txt > this_script.pl
# Lance Braswell @lance_braswell
my $aligned_cnt = 0;
my $notaligned_cnt = 0;
my $cnt = 0;
my $sector = 512;
my $align_check = 4096;
my $lba_multiple = int($align_check/$sector);
while (<>) {        chomp;        if ( /^\d+,(\d+),\d+,(read|write),(\d+),(\d+)$/ ) {                my ($sizeb,$op,$lba,$timeus) = ($1,$2,$3,$4);                my $mod = $lba % $lba_multiple;                my $value = $lba/$lba_multiple;                if ( $mod ) {                        $notaligned_cnt++;                } else {                        $aligned_cnt++;                }                $cnt++;        }
}
print "Total IOs: $cnt, 4K aligned: $aligned_cnt, not 4K aligned: $notaligned_cnt\n";

 

 

Lance Braswell

@lance_braswell


Viewing all articles
Browse latest Browse all 403

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>