SSDに関する検証 その4

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

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

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

▼ 前回のおさらい

SSD を導入するメリットは、I/O の高速化ということだけではありません。

ディスクがボトルネックとなっている状況で、CPU 使用率を観察すると
%iowait の占める割合が高く、相対的に %user が非常に低くなってしまうこ
とが確認できました。

https://www.insight-tec.com/img/ora3/Config1_CPU.JPG

ユーザ・アプリケーションに割り当てられる CPU リソースが極端に少なく
なる。結果としてスループットが非常に悪くなる。ということが解りました。

一方、SSD を導入すると、%iowait が非常に低くなるため、%user が高い
つまり、CPU リソースがユーザ・アプリケーションに効率的に回されるために
スループットが格段に向上する。ということも解りました。

https://www.insight-tec.com/img/ora3/Config2_CPU.JPG

▼ SSD の使いどころを考える。

DBA にとってパフォーマンス問題は頭の痛いものです。

・アプリケーションを開発した人が退職等で居なくなってしまった。
・市販のパッケージ製品なので、SQL に手を加えることができない。
・業務の性格上、大量の I/O は避けられない…

等々、いろいろな障壁があるにも関わらず、エンドユーザからは「とにかく、
早く何とかしてくれ!!」というプレッシャーにさらされている DBA の方々
は沢山いらっしゃるのではないでしょうか?

ディスクI/O がボトルネックとなっているシステムにおいて、SSDは即効性
のある最強のソリューションです。

とにかく、あまり考えなくても確実に速くなるのですから DBA にとってこ
んなにうれしいことはありません。

しかし、一つ大きな問題があります。そう、容量です。

今回、検証で使用している SSD は 16GB の容量です。今の世の中、全体で
16GB に収まるような DB は、まずないでしょう。
TB(テラバイト)級の DB というのが当たり前の時代になっています。

そこで、ユーザ表領域のデータファイル以外で I/O 負荷の高いファイル、
しかも SSD に十分置けるサイズのファイルを SSD化することによって、パ
フォーマンスがどれくらい改善されるのかを検証してみます。

▼ 検証2:特定のファイルを SSD 上に置いてみる。

検証1では、検証環境の制約で、比較対象となる磁気ディスクは内蔵ディス
ク(RAID5)のみだったため、SSD との純粋な比較ができませんでした。
しかし、SSD に有利になり過ぎる条件では、やはりフェアな結果とは言えま
せんので、新たに検証環境を構築することにしました。

◆ 環境

Linux 2.6.9-42.0.0.0.1.ELhugemem
Intel(R) Xeon(R) CPU 3.00GHz
実メモリ:4GB
内蔵ディスク   RAID5 SCSIデバイス名: /dev/sda
外付けディスク RAID5 SCSIデバイス名: /dev/sdb
  REDOログ用    : /dev/sdb6  ../mgd/redo/redo1_1.log
                                          redo2_1.log
                                          redo3_1.log
  ユーザ表領域用: /dev/sdb8  ../mgd/data/mgd_tbs01.dbf
  TEMP 表領域用 : /dev/dbb9  ../mgd/temp/temp01.dbf
  UNDO 表領域用 : /dev/sdb10 ../mgd/undo/undotbs01.dbf

外付け SSD           SCSIデバイス名: /dev/sdc
  REDOログ用    : /dev/sdc7  ../mgd/redo/redo4_1.log
                                          redo5_1.log
                                          redo6_1.log
  ユーザ表領域用: /dev/sdb1  ../ssd/data/ssd_tbs01.dbf
  TEMP 表領域用 : /dev/dbb3  ../ssd/temp/ssd_temp01.dbf
  UNDO 表領域用 : /dev/sdb2  ../ssd/undo/ssd_undo01.dbf(2GB)

◆ 検証スクリプト

検証環境がパワーアップしたので、かける負荷も激しくしてみました。

(1) テーブル作成(レコード長 約1,000バイト)
(2) インデックス作成(複合索引、索引長 約1,000バイト)
(3) 約1,000バイトのレコードを3万件 INSERT (1,000件毎にコミット)
(4) テーブル削除

これら一連の処理を、同時 20 セッションで実行してみました。

◆ データファイル I/O の状況

SSD の検証をする前に、すべてのデータファイル、REDO ログファイルが、
磁気ディスクにある状況(Config1)でのスクリプト実行結果を確認したとこ

Config1 : 19m 47s
——-
となりました。

また、この時の WORKLOAD REPOSITORY report(Oracle9i までの STATSPACK
report に相当)から抜粋した、データファイル I/O の状況は以下のとおりで
す。

                                                  Av  Buffer Av Buf
TS       Filename                    Writes Writes/s   Waits Wt(ms)
-------- -------------------------- ------- -------- ------- ------
UNDOTBS1 ../mgd/undo/undotbs01.dbf  246,590      195   7,981  289.7
MGD_TBS  ../mgd/data/mgd_tbs01.dbf  174,962      138   2,846   78.2
SYSTEM   ../mgd/misc/system01.db        201        0     169   32.5
TEMP     ../mgd/temp/temp01.dbf           3        0       0    N/A

意外と、UNDO 表領域への書き込み負荷が高いことがわかります。

それでは、UNDO 表領域のデータファイルのみを SSD に置いて検証してみま
しょう。(Config3-1)

SQL> alter system set undo_tablespace=ssd_undo;

システムが変更されました。

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

◆ UNDO 表領域のみを SSD に置いた場合(Config3-1)

UNDO のみを SSD化するだけで、どれくらいパフォーマンスが向上するので
しょうか?

前置き抜きに結果をご紹介します。

Config3-1 : 8m 14s (Config1比 2.4倍)
——
いかがでしょうか。既存のデータベースにほとんど変更を加えることなく、
2.4倍のパフォーマンス向上を実現しました。

それでは、WORKLOAD REPOSITORY report から両者の違いを客観的に見てみ
ましょう。

1ページ目には、「Load Profile(負荷特性)」という部分があります。
以下は両者の抜粋となります。

Load Profile(Config1)
                      Per Second  Per Transaction
                 ---------------  ---------------
      Redo size:    2,882,126.49    10,230,644.83
  Block changes:        3,574.06        12,686.80
Physical writes:          349.52         1,240.69
       Executes:          491.69         1,745.33
   Transactions:            0.28

Load Profile(Config3-1)
                      Per Second  Per Transaction
                 ---------------  ---------------
      Redo size:    6,397,299.14    24,613,738.14
  Block changes:        8,944.28        34,413.32
Physical writes:          844.43         3,248.97
       Executes:        1,123.84         4,323.99
   Transactions:            0.26

“Per Second”は、秒間あたりの統計値となり、スループットを表します。

また、’Transactions’の値がほとんど同じということにも注目しましょう。
これは、スクリプトの INSERT および COMMIT はループの中で実行されており
1つの SQL が投げられる速さというのは、1回のループの速さであり、基本的
に常に同じです。

両者のディスク書き込み(UNDO 表領域)の違いによって、スループットに
約 2.4倍の差が出たことがお解かりになったでしょうか?

何百 GB もの UNDO 表領域を使い、処理の最後に 1回だけコミットを行うよ
うな仕様は、常に正しいのでしょうか?

今回の検証で行ったように、例えばループ 1,000回につき 1回のコミットを
行うようにしておけば、それ程巨大な UNDO 表領域は必要ありません。

今回は 2GB の UNDO 表領域でしたので、16GB の SSD では十分実用的な大
きさの UNDO 表領域を確保することができるのではないでしょうか?

次回は、UNDO に加え オンライン REDO ログファイルを SSD化して更なる
高速化に挑戦します!!

今回はここまで!!

2007アジアカップ 日本代表は初戦のカタールに引き分け!
これがホントの「惜しむ監督」

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