連載
» 2006年08月25日 00時00分 公開

I/Oチューニングを成功させる必修ポイントDr. K's SQL Serverチューニング研修(6)(3/3 ページ)

[熊澤幸生, 工藤淳(インタビュアー),CSK Winテクノロジ/オフィスローグ]
前のページへ 1|2|3       

1つのパーティションにすべてのファイルを入れない

 SQL Serverのワークロードの中でも特にI/O負荷の高いファイルが複数あるなら、それらを1つのパーティションに入れるのではなく、異なるパーティションに分けて入れることによって、ディスクサブシステムの負荷=ディスクレベルでの負荷を分散できます。これが、I/O負荷分散を考えていくときに、いちばん最初のアプローチです。

 SQL Serverのチューニングで非常に多く見られる良くないケースが、1つのパーティションに全部のファイルを入れているユーザーです。こういう使い方をすると、先にも紹介した「Disk Queue Length」という現象が発生します。ある特定のパーティションに対して、非常に高いI/O負荷が集中した結果、待ち行列が発生するわけです。「Disk Queue Length」の発生が一時的なものならばよいのですが、慢性的に起こるようでは問題です。もともと基本的には、「Disk Queue Length」はゼロであるべきもので、通常時にはほとんど発生してはいけないとされています。

 このカウンタ値を調べていくと、どのオブジェクトが入っているパーティションの負荷が高いかが分かります。その負荷の高いパーティションを見つけ出したら、そこにはデータベースのどういうファイルが入っているのか、またそれらは分割することができるかどうかを検討しなくてはなりません。こうした手法を用いて、前ページで紹介したシステムをチューニングした後の状態を図4と図5に示します。

図4 前ページの図2のチューニング後の状態。縦軸の単位が図2とは大幅に異なっている点に注意(画面をクリックすると拡大します) 図4 前ページの図2のチューニング後の状態。縦軸の単位が図2とは大幅に異なっている点に注意画面をクリックすると拡大します
図5 前ページの図3のチューニング後の状態。縦軸の単位が図3とは大幅に異なっている点に注意(画面をクリックすると拡大します) 図5 前ページの図3のチューニング後の状態。縦軸の単位が図3とは大幅に異なっている点に注意画面をクリックすると拡大します

 異なるパーティションにI/O負荷を分散させるとはいうものの、実際にデータベースを使用している現場で問題なのは、ストレージとデータベースとでは管理担当者や部署がまったく別だったりすることです。ストレージの構成は、担当の専門部署以外は分かりません。また、既存ストレージ上のパーティションの変更と追加には、ストレージ技術者の人的コスト、新たな物理ディスクの購入、移行用の一時的なストレージの確保、移行データ整合性の検証などの大きなコストと時間が必要となります。このため新しくデータベースサーバを立てようと思ったら、データベース担当者は、どれくらいの大きさのパーティションをどういったRAID構成でいくつ用意してくださいといった申請をストレージ部門に行うのが一般的です。もちろんシステム構築の途中で急な変更や追加があっても、即座に対応することは簡単ではありません。

 そういった現実的な制約もあって、I/O負荷分散というのは後から対応しようと思っても、環境が許さない部分が非常に大きいのです。本当は、I/O負荷分散のチューニングというのは、本稼働の前に念入りに行っておくことが必要なのですが、往々にしてSQL Serverの場合、誰でも簡単に立ち上げることができるため、適当にチューニングして立ち上げてみて、これではパーティションが足りないといったことがしばしば起こっているのが実情です。新たなパーティションの確保のために、六カ月を超える期間が必要な例も数多く見受けられます。

パーティションを分けたら、それに最適なRAID構成を考える

 ここまで、入れ物=パーティションを分けることが必要だという話をしました。では次に、「それに最適なRAIDの構成とは?」ということを考えてみましょう。一般的にはRAID1+0ですべてのパーティションを組むのが、最も高いパフォーマンスを得られます。もちろんRAID5で作っているユーザーもいますが、SQL Serverから見て最高のパフォーマンスが出るのは、「パリティなしのストライピングセットを2重化して持つ」という構成です。

 そして次には、RAIDに必要なディスクが何枚あればいいかを考えます。SQL Serverユーザーでよく見られるハードウェアの構成というのは、CPUの物理ソケットを4つ積んだサーバマシンです。そこにメモリを8Gbytes、さらにその下にファイバチャネル経由の比較的安価なストレージに70Gbytesくらいのディスクを12〜16枚つなげているといったパターンです。

 仮に16枚のディスクがあった場合、上述のようにSQL Serverには4つのパーティションがあればいいので、各パーティションに4枚のディスクを与えます。この場合、2+2のRAID1+0が作れて、これが4つで16個になります。

 そういう構成を作るだけでも、SQL Serverから見ると非常に良くチューニングされたディスクサブシステムということになると思います。それによって、お互いのI/Oの要求がケンカすることなく負荷が分散されて、ディスクシステムとSQL Serverがスムーズにやりとりできるようになるのです。

 ただ過去の経験でいうと、1つのパーティションの上にすべてのSQL Server関連のファイルを配置しているようなユーザーに、こうした4つのパーティションを作ってこういうRAID構成にしてほしいと要望を出すと、データの引っ越しが大変だとか、もうディスクが空いていないとか、いろんな問題が出てくるケースが少なくありません。データベースを立てるときには、将来I/Oの負荷が高くなってもきちんとチューニングができるような構成を考えて、ストレージをプランしていくことが重要だと思います。それが今回でいうI/Oの負荷分散の概要と、物理ファイルのオブジェクト配置の関係です。


 次回は、初期アロケーションサイズの見積もりを正しく行うために必要となる、より高度な知識を解説します。(次回へ続く)

監修者プロフィール

株式会社CSK Winテクノロジ 執行役員 兼 技術推進担当。

熊澤 幸生(くまざわ・ゆきお)

メインフレーム環境で20年近くデータベース関連のITプロジェクトを数多く経験。また1979年から1983年まで米国に駐在し、データ主導型システム設計を実プロジェクトで学ぶ。1994年、アスキーNT(現、CSK Winテクノロジ)設立に参加し、SQL Server Ver 4.2からSQL Server 2000までシステム構築、教育にかかわってきた。現在同社執行役員 Chief Technology Officer。また、SQL Serverユーザー会「PASSJ」の理事として活動中。



前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。