SSDに関する検証 その４
＜緊急特集！！SSDに関する検証 その４＞
ペンネーム： ミラニスタ
磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
SSD (Solid State Disk) の検証を行っています。
検証製品（富士ゼロックス株式会社様製 GigaExpress）の紹介URL⇒
http://www.fujixerox.co.jp/product/gigaexpress/
▼ 前回のおさらい
SSD を導入するメリットは、I/O の高速化ということだけではありません。
ディスクがボトルネックとなっている状況で、CPU 使用率を観察すると
%iowait の占める割合が高く、相対的に %user が非常に低くなってしまうこ
とが確認できました。
https://old.insight-tec.com/img/ora3/Config1_CPU.JPG
ユーザ・アプリケーションに割り当てられる CPU リソースが極端に少なく
なる。結果としてスループットが非常に悪くなる。ということが解りました。
一方、SSD を導入すると、%iowait が非常に低くなるため、%user が高い
つまり、CPU リソースがユーザ・アプリケーションに効率的に回されるために
スループットが格段に向上する。ということも解りました。
https://old.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化することによって、パ
フォーマンスがどれくらい改善されるのかを検証してみます。
▼ 検証２：特定のファイルを SSD 上に置いてみる。
検証１では、検証環境の制約で、比較対象となる磁気ディスクは内蔵ディス
ク（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化して更なる
高速化に挑戦します！！
今回はここまで！！
２００７アジアカップ 日本代表は初戦のカタールに引き分け！
これがホントの「惜しむ監督」
今日も天気が悪い 茅ヶ崎にて