SSDに関する検証 その5

投稿日: 2007年7月18日

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

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

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

今回は一番最後に SSD に関するミニ・クイズがあります!!
回答いただいた方、抽選で10名様に富士ゼロックス様ご提供の素敵なノベル
ティグッズを差し上げます。奮って、ご応募ください。

▼ 前回のおさらい

SSD は限られた容量なので(検証製品は 16GB)、DB 全体ではなく一部の
ファイルを SSD 化することによって、どれだけの高速化を実現できるかを検
証しました。

最初に、UNDO 表領域のデータファイルに着目しました。

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

この2つの形態におけるバッチ処理(3万件の Insert を同時 20セッション
で実行)を比較したところ

Config1 : 19m 47s
Config3-1 : 8m 14s (Config1 比 2.4倍)

という結果を得ました。

▼ 検証3:REDO も SSD 化しちゃう!!

UNDO 以上に高速なディスクに配置する必要があるのが、オンライン REDO
ログファイルです。

オンライン REDO ログファイルをなぜ高速なディスクに配置しなければなら
ないのかは、

TOP

「REDOログに関する検証」(2001.07.05 ~ 10.31 古い!)

を参照してください。

ファイル                       Config1       Config3-2
------------------------------ ------------- -------------
SYSTEM 表領域                  磁気ディスク  磁気ディスク
ユーザ表領域                   磁気ディスク  磁気ディスク
UNDO 表領域                    磁気ディスク  SSD(2GB)
一時表領域                     磁気ディスク  磁気ディスク
オンライン REDO ログファイル   磁気ディスク  SSD(150MB * 3)

また、オンライン REDO ログファイルを磁気ディスクから SSD に変更する
方法については、「SSDに関する検証 その2」

SSDに関する検証 その2

を参照してください

・Config1、Config3-2 共に REDO ログファイルの大きさは 150MB です。
・両者ともノーアーカイブモードです。

▼ 結果は?

同様に、3万件の Insert を同時 20セッションで実行した結果は、以下のと
おりでした。

Config1 : 19m 47s
Config3-2 : 5m 16s (Config1 比 3.8倍)
=======
いかがでしょうか。REDO と UNDO を SSD化するだけで、約 4 倍の性能向上
を実現することができました。

ユーザ表領域が I/O ボトルネックとなっているので、検証1でお見せした
13.5 倍のパフォーマンスアップとまではいきませんが、同じアプリケーショ
ンが何の修正もなしに 4 倍速くなるというのは魅力です。

WORKLOAD REPOSITORY report から、待機イベントのクラスごとの状況を確
認してみましょう。

○ Config1
                                                 Avg
                           %Time  Total Wait    wait     Waits
Wait Class          Waits  -outs    Time (s)    (ms)      /txn
-------------- ---------- ------ ----------- ------- ---------
Configuration   6,644,845   99.7      18,384       3  18,613.0
Concurrency        12,237   18.4       2,505     205      34.3
Other              37,204   34.5       1,281      34     104.2
Application           229   80.3         600    2621       0.6
System I/O         25,204     .0         105       4      70.6
Commit                162     .0          11      66       0.5
User I/O            4,382     .0           7       2      12.3
Network             1,844     .0           0       0       5.2
          --------------------------------------------

○ Config3-2
                                                 Avg
                           %Time  Total Wait    wait     Waits
Wait Class          Waits  -outs    Time (s)    (ms)      /txn
------------- ----------- ------ ----------- ------- ---------
Configuration     436,589   96.5       1,767       4   2,910.6
Other             283,286    1.2       1,333       5   1,888.6
Concurrency       271,178     .3         988       4   1,807.9
Application           141   61.7         303    2148       0.9
System I/O         99,742     .0          39       0     664.9
User I/O            4,389     .0           4       1      29.3
Commit                 99     .0           1       9       0.7
Network               899     .0           0       0       6.0
          --------------------------------------------

Config1, Config3-2 に共通して大きな割合を占める「Configuration」とい
う待機イベントのクラスの値が、両者でかなり違いがあることがわかります。

「Total Wait Time (s)」を比較すると、10倍以上も違います。

この待機イベントのクラスは、データベースの構成やインスタンスのリソー
スに起因するもので、10gR2 では以下のようなイベントが含まれます。

SQL> select event from v$system_event where wait_class='Configuration'
          order by event;

EVENT
----------------------------------------
enq: HW - contention
enq: SQ - contention
enq: TX - allocate ITL entry
free buffer waits
latch: redo copy
latch: redo writing
log buffer space
log file switch (checkpoint incomplete)
log file switch completion
sort segment request
undo segment extension
write complete waits

12行が選択されました。

UNDO や REDO 関連の待機イベントが多く含まれていますね。

これら、Oracleにとっての”キモ”となるファイル群を、SSD 上に配置する
ことで高速化すればパフォーマンスが向上することがお分かりいただけました
でしょうか。

ここまでのベストプラクティス:「SSD は、UNDO と REDO で使おう!!」
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
つい最近訪問させていただいたお客様は、あるバッチ処理の時間がかかり過
ぎるという問題を抱えておられました。
詳しくヒアリングしてみると、市販のアプリケーションのため SQL の書き
換えやロジックの見直しということが基本的に不可能なケースでした。

これが、I/O ボトルネックであれば間違いなく SSD をお勧めするでしょう。

また、自主開発アプリであっても、何ヶ月もかけて(つまり、コストも時間
も)改修をするより、SSD を導入するだけでパフォーマンスを簡単にアップさ
せることができ、しかも改修に伴うリスクに悩む必要がありません。

▼ SSD ミニ・クイズ

今までのメルマガの内容と GigaExpress の製品紹介ページから簡単なクイズ
を出題します。
回答していただいた方の中から抽選で10名様に、富士ゼロックス様ご提供の
素敵なノベルティグッズを差し上げますので奮ってご応募ください。

応募先 mailto:letter@insight-tec.co.jp (担当:三原)

====================================================================
Q1. SSD とは何の略?

Q2. Linux におけるハードディスクのベンチマークテストを簡単に行うことが
できるツールは?

Q3. 磁気ディスクを回転させ目的の位置まで読み取りヘッドを移動させるため
の時間のことを何と呼ぶ?

Q4. GigaExpress シリーズの転送速度は?

Q5. iostat -x における、wkB/s は何?

Q6. SSDを導入するメリットは「ボトルネックをディスクから ○○○ にシフ
トさせる」ことである。○○○は?

Q7. GigaExpress 16G-1P の標準価格(税別)は?

Q8. メルマガの中で、UNDO と REDO を SSD 化した場合の、性能改善比は?

Q9. 今年のUEFAチャンピオンズリーグ優勝チームは?

Q10. 機会があれば SSD の性能を体験してみたいですか?(自由記述)

====================================================================

今回はここまで!

台風、地震と大変な3連休でした。

今日も天気が悪い 茅ヶ崎にて