SSDに関する検証 その２
＜緊急特集！！SSDに関する検証 その２＞
ペンネーム： ミラニスタ
磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
SSD (Solid State Disk) の検証を行っています。
▼ 前回のおさらい
Linux における Raw デバイスのベンチマークテストを比較的簡単に実施で
きる hdparm というツールを使って、磁気ディスクと SSD の性能比較を行っ
てみました。
磁気ディスク： 35.63 MB/sec SSD ：318.66 MB/sec
という、約9倍の性能比が得られました。
▼ 検証１：関連ファイルをすべて SSD 上に置いてみる。
それでは、早速最初の検証に取り掛かります。
主に I/O が発生すると思われる以下のファイルを SSD 上に置くことにしま
す。(Config2)
・ユーザ表領域のデータファイル
・UNDO 表領域のデータファイル
・一時表領域のデータファイル
・オンライン REDO ログファイル（SIZE = 100MB）
◆ 環境のおさらい
Linux 2.4.21-32.EL
Intel(R) Xeon(TM) CPU 2.80GHz
実メモリ：8GB
内蔵ディスク RAID5 SCSIデバイス名： /dev/sda
外付け SSD SCSIデバイス名： /dev/sdb
/dev/sdc
SSD は 2台接続していますが、今回は /dev/sdb のみ使用します。
また、比較のために、上記ファイルを /dev/sda に置いた構成も準備しまし
た。（Config1）
◆ 構成のまとめ
ファイル Config1 Config2 補足説明 ------------------------------ ------------- ------------- -------- SYSTEM 表領域 磁気ディスク 磁気ディスク ユーザ表領域 磁気ディスク SSD 1 UNDO 表領域 磁気ディスク SSD 2 一時表領域 磁気ディスク SSD 3 オンライン REDO ログファイル 磁気ディスク SSD 4
＊補足説明
1. ユーザ表領域は、磁気ディスク上、SSD上にそれぞれ作成しておき、テーブ
ル作成時にどちらかを選択します。
2. UNDO 表領域も、磁気ディスク、SSD上にそれぞれ作成しますが、
alter system set undo_tablespace = ;
で必要に応じいずれかに切り替えます。
3. 一時表領域は、Config1 検証用ユーザ、Config2 検証用ユーザをそれぞれ
作成する際に、TEMPORARY TABLESPACE 句で磁気ディスク、SSD上に作成し
た一時表領域を指定します。
例：
create user FXSSD …. temporary tablespace TEMP_SSD …
^^^^^^^^
4. オンライン REDO ログファイルはちょっと面倒です…
現在、REDO ログファイルが、磁気ディスク上に作成されていて（グループ
1 – 3）、SSD に切り替えるという想定で説明します。
4-1. 現在のステータス確認
select l.group#,l.sequence#,f.member,l.members,l.status from v$log l,v$logfile f where l.group#=f.group# order by 1,3; GROUP# SEQUENCE# MEMBER MEMBERS STATUS ---------- --------- ----------------------- --------- -------- 1 xxxx .........../redo1-1.log 1 INACTIVE 2 xxxx .........../redo2-1.log 1 INACTIVE 3 xxxx .........../redo3-1.log 1 CURRENT
4-2. SSD 上にグループ 4 – 6 の REDO ログファイルを追加
alter database
add logfile
group 4 ('/fxssd/fxssd1/log/redo4_1.log') size 100m reuse,
group 5 ('/fxssd/fxssd1/log/redo5_1.log') size 100m reuse,
group 6 ('/fxssd/fxssd1/log/redo6_1.log') size 100m reuse;
4-3. グループ 1 – 3 の REDO ログファイルのステータスが「INACTIVE」
になるまで、ログスイッチを繰り返す。
alter system switch logfile;
4-4. ステータスが「INACTIVE」となったグループ 1 – 3 を削除する。
alter database drop logfile group ;
また、本検証は「ノーアーカイブログモード」で実施しました。
◆ 検証用処理
書き込み負荷の高い、バッチを想定した処理を実行させました。
1) Config1 検証用ユーザ、Config2 検証用ユーザのいずれかで接続
例：
sqlplus -s “fxssd/fxssd”
2) レコード長 約1,000バイトのテーブルを作成
create table (
id number,
data1 varchar2(100),
data2 varchar2(100),
………………..
data10 varchar2(100)
) tablespace ;
3) 約1,000バイトのデータを INSERT（1件毎コミット）
ループ回数分繰り返し
for i in 1.. loop
INSERT into values (i,
” — data1
,” — data2
…………………..
,”; — data10
commit;
end loop;
4) テーブル削除
drop table purge;
上記、1) から 4) の処理を１つのスクリプトの中で続けて実行し、これ
を、同時に 10 スクリプト走らせました。つまり 10 同時セッションで 10
個のテーブルにそれぞれ INSERT を行います。
◆ 結果発表！！
ループ回数を 20万回、すなわち約1,000バイトのレコードを 20万回 * 10
セッション = 200万行 の INSERT 処理を、Config1 と Config2 で実行させた
結果は
↓↓↓↓↓↓↓↓↓↓
Config1 : 1h 18m 27s
Config2 : 0h 05m 50s
すごい！ベンチマークの結果を上回る約 13.5 倍のスループットを記録しまし
た！！
▼ 速さの理由（わけ）
ただし、単純に所要時間の比較をするだけでは意味がありません。処理デー
タ量が多ければもっと差が開くでしょうし、逆に少なければこんなに差は出な
かったはずです。
そこで iostat を使って両者の違いを客観的に確認してみることにします。
◆ iostat とは？
ディスクのパフォーマンスを確認するには、iostat は最も有用なツールで
す。
$ iostat [オプション] [デバイス名] [インターバル秒数]
で、インターバル秒数毎の各デバイスの統計情報を取得します。
○ オプション
-x : 拡張統計情報 extended statistics の出力
-t : 時間情報の出力
○ 主なカラム
rkB/s : 1秒あたりの読み込み KB 数 wkB/s : 1秒あたりの書き込み KB 数 avgqu-sz : 平均 I/O キュー数（この値が高い場合は要注意） %util : ディスク使用率？ビジー率？（100 に近いほど性能限界）
○ 使用例（結果をファイルに出力する場合）
$ iostat -x -t sda sdb 2 > iostat_xxxxxx.log
Linux 2.6.9-42.0.0.0.1.ELhugemem (xxxxxxxxx) 2007年06月XX日
CPU平均: %user %nice %sys %iowait %idle
0.73 0.00 0.27 0.20 98.79
デバイス: .... rkB/s wkB/s .... avgqu-sz .... %util
sda .... 4.91 14.39 .... 0.04 .... 0.53
sdb .... 0.03 0.00 .... 0.00 .... 0.00
説明が長くなってしまいました。。。
衝撃の検証結果については次回までのお楽しみとさせてください。
今回はここまで！！
リーガ・エスパニョーラはレアル・マドリッドが優勝です！！
バルサは残念でした！
やっと梅雨らしくなってきた茅ヶ崎にて