SSDに関する検証 その9

投稿日: 2007年8月22日

<緊急特集!!SSDに関する検証 その9>
ペンネーム: ミラニスタ

磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
SSD (Solid State Disk) の検証を行っています。

検証製品(富士ゼロックス株式会社様製 GigaExpress)の紹介URL⇒
http://www.fujixerox.co.jp/product/gigaexpress/

▼ 前回のおさらい

前回は、読み込み処理(Select)における、磁気ディスクと SSD の比較を
行ってみました。

検証では、200 個の比較的小さな表(10,000レコード)を、それぞれ別の
セッションで同時に全件検索させてみました。
^^^^^^^^

ファイル                       Config5-1         Config5-2
------------------------------ ----------------- -------------
SYSTEM 表領域                  磁気ディスク      磁気ディスク
ユーザ表領域                   磁気ディスク(sdb) SSD(sdc)
UNDO 表領域                    磁気ディスク      磁気ディスク
一時表領域                     磁気ディスク      磁気ディスク
オンライン REDO ログファイル   磁気ディスク      磁気ディスク

また、Select の場合は、DBバッファ・キャッシュの大きさもパフォーマン
スに影響を与えそうなので、

DB_CACHE_SIZE = 1024M : Config5-1-1, Config5-2-1
DB_CACHE_SIZE = 128M : Config5-1-2, Config5-2-2

という全部で 4 つのパターンで検証しました。
(各パターンの実施前にはDBバッファ・キャッシュをクリアしています。)

▼ 結果の考察

1) OS リソースの状況(iostat抜粋)

◆ Config5-1-1 (磁気ディスク、DB_CACHE_SIZE = 1024M)

CPU平均:  %user   %nice    %sys %iowait   %idle
          92.71    0.00    7.29    0.00    0.00

デバイス:    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdb       40731.70     2.10   243.62     1.87    5.61   2.64  88.20

◆ Config5-2-1 (SSD、DB_CACHE_SIZE = 1024M)

CPU平均:  %user   %nice    %sys %iowait   %idle
          91.50    0.00    8.50    0.00    0.00

デバイス:   rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdc      39575.15     2.40    15.99     1.10    0.22   0.02  11.86

◆ Config5-1-2 (磁気ディスク、DB_CACHE_SIZE = 128M)

CPU平均:  %user   %nice    %sys %iowait   %idle
          92.65    0.00    7.35    0.00    0.00

デバイス:    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdb       40994.10     9.30   240.91     1.15    3.37   2.12  72.20

◆ Config5-2-2 (SSD、DB_CACHE_SIZE = 128M)

CPU平均:  %user   %nice    %sys %iowait   %idle
          90.31    0.00    9.69    0.00    0.00

デバイス:   rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sdc      39918.09    17.50    16.01     1.10    0.22   0.02  11.35

Insert の場合は、ディスクビジー率(%util)が高い、つまりディスクの性
能限界が近いときに、CPU のI/O待ち(%iowait)の割合が高くなり、相対的に
ユーザアプリケーションに回される CPU リソース(%user)が低く抑えられて
しまう、ディスクボトルネックの状態が見られました。

そのような場合、磁気ディスクを SSD にするだけで、%user が高くなり、
スループットが向上するということもわかりました。

ところが、Select の場合はちょっと傾向が違うようです。

磁気ディスクの方が確かにディスクビジー率は高い(8倍)のですが、%iowait
がどの場合でも発生しておらず、%user が高い水準です。(90%以上)

磁気ディスク、SSD 間で %user がほとんど変わらないということは、SQL
のレスポンスにもほとんど差がありませんでした。(結果は割愛します。)

また、1秒あたりの読み込み KB 数(rkB/s)は、SSD よりむしろ磁気ディス
クの方が上回っています。この結果だけを見ると Select は SSD の性能を十分
生かし切っていないようにも見えます。

2) 待機イベント

◆ Config5-1-1 (磁気ディスク、DB_CACHE_SIZE = 1024M)

EVENT                            Waits  Time Waited
------------------------------- ------ ------------
db file scattered read           20004        14773
db file sequential read            417        22432
read by other session              195        12068
control file sequential read        70            1
log file parallel write             32           21
control file parallel write         22           34
direct path write                    2            0

◆ Config5-2-1 (SSD、DB_CACHE_SIZE = 1024M)

EVENT                            Waits  Time Waited
------------------------------- ------ ------------
db file scattered read           20013         7387
db file sequential read            424         2530
control file sequential read        71            2
log file parallel write             42           24
control file parallel write         22           37
read by other session               14          305
direct path write                    2            0

◆ Config5-1-2 (磁気ディスク、DB_CACHE_SIZE = 128M)

EVENT                            Waits  Time Waited
------------------------------- ------ ------------
db file scattered read           20078        22371
db file sequential read            659        34185
read by other session              514        46831
control file sequential read        67            2
log file parallel write             35           25
control file parallel write         23           35
direct path write                    2            0

◆ Config5-2-2 (SSD、DB_CACHE_SIZE = 128M)

EVENT                           Waits  Time Waited
------------------------------ ------ ------------
db file scattered read          20128         4933
db file sequential read           718         3321
control file sequential read       71            1
log file parallel write            42           18
control file parallel write        23           40
read by other session              11          775
direct path write                   2            0

それでは、待機回数の多い順に見ていきましょう。

まずは、”db file scattered read”。今回の検証では全件検索を行わせてみ
ましたが、全件検索のように複数ブロックを読み込む際に発生する待機イベン
トです。従ってこのイベントが最上位に来るのは予想通りです。

4 つのパターンで、待機回数にほとんど違いがないことに気がつかれたでしょ
うか?これは検証してみてわかったのですが、”db file scattered read”の待
機回数自体は DBキャッシュの大きさやディスク性能の違いによる変化があまり
ありませんでした。(これは、更なる追求が必要ですが、SSD とは直接関係し
ないので、別に機会に検証してみたいと思います。)
ちなみに、DBキャッシュをクリアせずに連続してスクリプトを実行させても
待機回数に大きな変化はありませんでした。(以下、参考情報参照)

参考:DBキャッシュをクリアせずに、連続 3回実行した場合(磁気、1GB)

1回目)
EVENT                          Waits Time Waited
------------------------- ---------- -----------
db file scattered read         20096       22831
db file sequential read          724       25989

2回目)
EVENT                          Waits Time Waited
------------------------- ---------- -----------
db file scattered read         20159       13829
db file sequential read          529         855

3回目)
EVENT                          Waits Time Waited
------------------------- ---------- -----------
db file scattered read         20135        5002
db file sequential read          546          85

*特に、待機時間の減少に注意!!

それでは、磁気ディスク vs SSD の比較をしてみましょう。
待機時間を待機回数で割った、1待機あたりの時間(1/100秒単位)を比較
すると以下のようになります。

No. Config      Disk  Cache   Time Waited(A)  Waits(B)  (A)/(B)
--- ----------- ----- ------- --------------- --------- --------
 1  Config5-1-1 磁気   1024MB           14773     20004     0.74
 2  Config5-2-1	SSD    1024MB            7387     20013     0.37
 3  Config5-1-2	磁気    128MB           22371     20078     1.11
 4  Config5-2-2	SSD     128MB            4933     20128     0.25

やはり、磁気ディスク vs SSD (1 vs 2, 3 vs 4) では、いずれも SSD の方
が待機時間が短くなりました。

次に多いのは、”db file sequential read”です。DB_CACHE_SIZE が小さい
ほど待機回数が多くなっていますが、磁気ディスクにおける待機時間では
“db file scattered read”よりもむしろ大きくなっています。

「全件検索なのになぜ?」という疑問が沸き起こってきませんか?
答えは、当メルマガのバックナンバーにあります。

<待ちイベントに関する検証 その7>
https://old.insight-tec.com/mailmagazine/ora3/vol327.html

・・・引用開始・・・
実際の環境で、全件検索が多くディスク I/O の多発している場合は全件検索
によるディスク I/O のボトルネックにより、インデックス検索などのシング
ルブロックへのアクセスが遅くなることが良くあります。この場合
“db file sequential read” が大きくなることがあるので(名前の問題もあり
ますが)こちらを全件検索の待ちイベントだと勘違いしてしまうことがありま
す。
・・・引用終了・・・

つまり、磁気ディスクの方は I/O ボトルネックとまでは行かなくても、I/O
負荷が高いために”db file sequential read”が大きくなっていると思われます。

その他、”read by other session”は磁気ディスクと SSD で傾向が大きく異
なります。この待機イベントは、あるセッションが別のセッションのブロック
読み込みを待っている状態つまり”buffer busy wait” の理由として 10g から
追加されました。
SSD の読み込み性能の優位性がこの待機イベントからわかるのではないでしょ
うか。

▼ まとめ

Select に関しては、SSD の導入メリットはあまり実感できなかったのでは
ないかと思います。
ミクロ的視点で見れば確かに、ディスクビジー率や読み込み性能の違いはわ
かるのですが、Insert のようにディスクの性能差が顕著に現れる場合とは異
なり、Select における Oracle はまさに「偉大なキャッシング・システム」
でした。
ディスクビジー率が 8 倍違っても、ユーザ CPU 使用率がほとんど同じとい
うのは、ある意味凄いことです。

Select については、パフォーマンス・チューニングの定石どおり、ロジカ
ル I/O の削減(インデックスの活用、SQL文の見直し)が王道なのではないか
と実感しました。(もちろん、ディスクがボトルネックとなっていて、アプリ
ケーションの仕様を容易に変更できない環境では SSD 導入は検討すべきでしょ
う。)

次回は、SSD の冗長化について検証してみたいと思います。

(ちょっと前ですが)全日本少年サッカー大会決勝を観に行きました。
最近の小学生はテクニックが凄いです!!

暑さが尋常でない茅ヶ崎にて