SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQLIO を使用したディスク I/O のベンチマーク

leave a comment

以前、SQLIOSIM を使用したストレステストの実施 という投稿を書きました。
SQL Server の IO パターンをテストするツールとして SQLIO Disk Subsystem Benchmark Tool (SQLIO) というツールもあります。

このツールを使用してディスク I/O のベンチマークを実施するための方法を軽くまとめてみたいと思います。
SQLIO, PowerShell and storage performance: measuring IOPs, throughput and latency for both local disks and SMB file shares もとても参考になりますのでこちらも一読してみるとよいかと。

■ツールの実行方法


SQLIOSIM は GUI から実行することができましたが SQLIO は CUI のみのツールとなっています。
また、SQLIOSIM では SQL Server の様々な挙動のシミュレーションができますが、SQLIO では以下のパターンのテストになると思います。

  • Sequential Read
  • Sequential Write
  • Random Read
  • Random Write

インストールをすると [C:Program Files (x86)SQLIO] に SQLIO のプログラム一式が格納されます。
# 私の環境は x64 の環境なので、(x86) にインストールされています。

[sqlio -h] を実行するとヘルプを表示することができます。
以下はヘルプの内容です。

sqlio v1.5.SG
-h: invalid option
Usage: sqlio [options] [<filename>…]
        [options] may include any of the following:
        -k<R|W>                 kind of IO (R=reads, W=writes)
        -t<threads>             number of threads
        -s<secs>                number of seconds to run
        -d<drv_A><drv_B>..      use same filename on each drive letter given
        -R<drv_A/0>,<drv_B/1>.. raw drive letters/number for I/O
        -f<stripe factor>       stripe size in blocks, random, or sequential
        -p[I]<cpu affinity>     cpu number for affinity (0 based)(I=ideal)
        -a[R[I]]<cpu mask>      cpu mask for (R=roundrobin (I=ideal)) affinity
        -o<#outstanding>        depth to use for completion routines
        -b<io size(KB)>         IO block size in KB
        -i<#IOs/run>            number of IOs per IO run
        -m<[C|S]><#sub-blks>    do multi blk IO (C=copy, S=scatter/gather)
        -L<[S|P][i|]>           latencies from (S=system, P=processor) timer
        -B<[N|Y|H|S]>           set buffering (N=none, Y=all, H=hdwr, S=sfwr)
        -S<#blocks>             start I/Os #blocks into file
        -v1.1.1                 I/Os runs use same blocks, as in version 1.1.1
        -F<paramfile>           read parameters from <paramfile>
Defaults:
        -kR -t1 -s30 -f64 -b2 -i64 -BN testfile.dat
Maximums:
        -t (threads):                   256
        no. of files, includes -d & -R: 256
        filename length:                256

 

SQLIO は外部ファイルにパラメーターを設定することができますので基本的には、コマンドラインではある程度のパラメーターのみを設定し、どのファイル (ドライブ) にどの程度のスレッドで実行するかをパラメーターファイルに記述することが多いと思います。

パラメーターファイルは以下のような形式になります。
最初に # を設定するとコメントになりますので、以下のパラメーターファイルでは実際に実行されるのは最初の行だけになります。

\172.16.0.1MountDisk1testfile1.dat 1 0x0 4000
#\172.16.0.1MountDisk2testfile1.dat 1 0x0 4000
#\172.16.0.1MountDisk3testfile1.dat 1 0x0 4000

このファイルですが、

  • 負荷をかけるファイルのパス
  • スレッド数
  • マスク
  • ファイルサイズ (MB)

という設定になり、どのファイルに何スレッドかけることができるかを調整することができます。

このファイルをもとにベンチマークテストを実行します。

よく使用するパターンとしては以下のような内容でしょうか。
各 I/O パターンを 64KB ブロックで 60 秒間、パラメーターファイルを使用しながらテストをしています。

sqlio -kR -s60 -fsequential -b64 -FParam.txt
sqlio -kW -s60 -fsequential -b64 -FParam.txt
sqlio -kR -s60 -frandom -b64 -FParam.txt
sqlio -kW -s60 -frandom -b64 -FParam.txt

 

実行すると、[IOs/sec] [MBs/sec] を取得することができますので、この値からディスクの I/O のパフォーマンスを調べていきます。

 

■データの整理方法


取得したデータの整理方法ですが、

  • 1 スレッド / 1 ファイルの情報
  • スレッドを増やしながら取得した情報
  • 各ファイル 1 スレッドの情報

というようなパターンを取得して情報を整理していきます。

1 スレッドで実行できる I/O がどの程度かを確認し、そのあとにスレッドを増やしていき、何スレッドで I/O が飽和するかを確認します。

具体的な数値は載せていませんが、スレッド数を変更していくと以下のような傾向になります。
4 → 5 スレッドにかけて、I/O の状態の変化が鈍くなっていますので、1 ファイルに対しては 5 スレッド程度で I/O が飽和しています。

image

次に 5 スレッドを 2 ファイル (合計 10 スレッド) に対して実行してみます。
ファイルを増やすたびに I/O が向上しているのが確認できます。
image

上記の結果は各ファイルを異なるドライブに配置しているのですが、これを同一のドライブに配置した場合の結果は以下のようになります。
image

今回使用している環境では、最適な I/O を出すためには SQL Server のファイルを格納するドライブを分ける必要があるということがここから見えてきます。

最大の I/O を発生させているときにどこでボトルネックが発生しているかはパフォーマンスモニターで取得した情報を照らし合わせるとわかってくるかと思います。

今回の環境では、SATA 2.0 のディスク接続なので、SATA の転送方式の上限に達してしまい 1 ドライブでは特定以上の I/O を発揮することができなくなっています。
# ディスクへの帯域不足が原因で I/O が飽和しています。

ディスクの性能に余裕があっても 1 スレッドあたりで処理できる I/O にも限界がありますので、1 処理で使用するスレッド数の調整も I/O を最大限に発揮させるためには重要となってきます。

SQLIO を使用すると SQL Server の I/O パターンを使用したシンプルなベンチマークを実行することができますので、ストレージの基本性能を確認したい場合にはこれを使用してどの程度まで処理ができるかを確認しておくとよいかと思います。

CPU の情報も取得しておくと接続方式による、CPU 負荷への影響も確認することができますのでこの辺も意識しておくとよいかもしれないですね。
# カーネルの CPU 使用率の情報を取得しておく必要が出てくると思いますが。

Written by masayuki.ozawa

4月 30th, 2013 at 11:29 pm

Posted in SQL Server

Tagged with

Leave a Reply

*