SSDに関する検証 その９
＜緊急特集！！SSDに関する検証 その９＞
ペンネーム： ミラニスタ
磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
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/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”よりもむしろ大きくなっています。
「全件検索なのになぜ？」という疑問が沸き起こってきませんか？
答えは、当メルマガのバックナンバーにあります。
＜待ちイベントに関する検証 その７＞
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 の冗長化について検証してみたいと思います。
（ちょっと前ですが）全日本少年サッカー大会決勝を観に行きました。
最近の小学生はテクニックが凄いです！！
暑さが尋常でない茅ヶ崎にて