SSDに関する検証　その１３ -最終回-

＜緊急特集！！SSDに関する検証　その１３ -最終回-＞
ペンネーム：ミラニスタ

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

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

▼ 前回のおさらい

2台の SSD をミラーリングすれば、うち 1台に故障が発生してもサービスの
継続は可能です。
ただし、冗長化が崩れた状態から復旧させるためには、（現状の製品では）
サーバのリブートが必要です。
次の製品リリースでは、ホットプラグが可能となるそうなので、サービスを
止めることなく復旧ができるようになります。

▼ 連載のまとめ

過去 12回にわたり SSD に関する検証を行ってきましたが、最後に検証結果
を振り返ってみたいと思います。

1. SSD の基本性能

Linux におけるハードディスクの簡単なベンチマークテストである
「hdparm -Tt」で、磁気ディスクと SSD の基本性能を比較してみました。
（検証その１）

磁気ディスク： 35.63 MB/sec
SSD         ：318.66 MB/sec

皆さんがお使いの環境（Linux）で是非このベンチマークテストをやってみ
てください。
100 MB/sec 以下であれば、SSD を導入した場合にその速さを実感していた
だけるのではないかと思います。

2. iostat でディスクボトルネックを調査する

ディスクがボトルネックとなるような状況を作り出して、SSD を導入した場
合との違いを見てみました。（検証その２～３）

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

＊磁気ディスク：sda、SSD：sdb

1) Config1

  $ iostat -x -t sda 2
  
  .....
  
  時間: xx時32分00秒
  CPU平均:  %user   %nice    %sys %iowait   %idle
             7.25    0.00    0.75   92.00    0.00
  
  デバイス:  ...    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
  sda2       ...  2252.00    15.45    68.86  207.32   3.43 100.00
  
  .....

2) Config2

  $ iostat -x -t sdb 2
  
  .....
  
  時間: xx時48分05秒
  CPU平均:  %user   %nice    %sys %iowait   %idle
            90.25    0.00    9.75    0.00    0.00
  
  デバイス:  ...    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
  sdb1       ... 12228.00    11.28     0.47    0.21   0.03   6.50
  
  .....

ディスクがボトルネックの場合は次のような特徴があります。
・CPU 使用率の %iowait が %user に比べて著しく高い。
・avgqu-sz（平均 I/O キュー数）が高い。
・%util（ディスクビジー率）が 100 に近い。（性能限界）

皆さんの環境で、特に書き込み負荷が高くてパフォーマンスの問題が起きて
いるようなことがあれば、iostat でディスクがボトルネックとなっていない
かどうか確認してみてください。

iostat で取得した CPU使用率の内訳をグラフ化し
https://old.insight-tec.com/img/ora3/Config1_CPU.JPG
のような状態になっていたら、完璧なディスクボトルネックの状態です。

%iowait は CPU が低速なディスク装置を待っている状態なので、SSD を導
入することで、相対的に %user の比率が高められ、ユーザ・アプリケーショ
ンのスループットが向上します。

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

ということは、%user や %sys が高くてレスポンスが悪い状態（多くの場合
Heavy な SQL によって、ロジカル I/O の比率が高い）に SSD を導入しても、
ディスクがボトルネックではないために、明確な効果は期待できないかもしれ
ません。

要するに、SSD 導入の可否はディスクボトルネックの有無によります。

3. SSD の弱点を克服する

本検証でご紹介した GigaExpress は DRAM ベースなので、書き換え回数制
限がなく、まさにデータベース向けの SSD と言えます。
しかし、電源瞬断や機器故障でデータが失われてしまうという宿命は、予想
以上に多くの方々が懸念されていることを、アンケートの結果や直接のお問い
合わせから実感しました。

そこで、検証その１０～１２では、Linux のソフトウェア RAID である
「mdadm」で SSD のミラーリングから、障害時のリカバリまでを行ってみまし
た。

詳細はバックナンバーを参照していただければと思いますが、結論としては
電源が供給されている限り SSD の冗長化は有効であり、重要なファイルを配
置しても概ね運用に耐えられると考えます。

さらに、本格的な運用を行うには、GigaExpress がホットスワップに対応す
べきであるとか、障害検知の仕組みをもっと確実に行うというようなハードル
はありますが、製品の更なる改良は富士ゼロックス様で前向きに検討されてい
るとお聞きしていますので、SSD は今後データベースのパフォーマンス問題に
対する有効なソリューションになり得ると確信しています。

4. SSD の有効活用法

順序が逆になりますが、検証その４～６、８では限られた容量の SSD をど
のように使うのが最もリーズナブルなのかを確認しました。

限られた検証でしたが「SSD は REDO と UNDO で使おう！！」というのがベ
ストプラクティスであると結論付けました。（性能改善比約4倍）

一方、ソート処理の高速化を期待して一時表領域の SSD 化を検証してみまし
たが、ソートに関しては sort_area_size を限界まで（一時的に）拡張するこ
との方がより効果的でした。

さらに、Select の場合も、Oracleのキャッシュが効いていて SSD のメリッ
トを十分に感じることはできませんでした。

ところで、オンライン REDO ログファイルを SSD に配置することにはどうし
ても抵抗を感じる、というご意見を沢山いただきました。

ということで前項の冗長化を検証したのですが、読者の皆さんはどのように
感じられたでしょうか？ご意見いただけると非常にうれしいです。

5. 最後に

担当者不在によりアプリケーションの改修が困難、あるいは改修に長期間を
要することによる高コストを懸念されて、SSD 導入に活路を見出そうとされて
いる方々が想像以上に沢山いらっしゃることがアンケートからわかりました。

この連載を通じて SSD に興味は持ったが、果たして自分の携わっているシ
ステムが SSD で改善できるのかわからない、という方は是非「Au-DBit+」
についてお問い合わせください。

この連載は今回で終わりです。皆さん、長い間ありがとうございました。

次回からは、10gでさらにパワーアップしたログマイナーについての検証が
始まります。乞うご期待！！

最近、朝が涼しい　茅ヶ崎にて

SSDに関する検証 その１３ -最終回-