合理的な考え方と正しい概念を学べば、
パフォーマンス・チューニングの正解に近づける
メモリ・チューニングの心構えは、正確なデータ取得
最近のデータベースの利用環境は、例えばチケットのオンライン予約やネット証券のように、システム管理者のピーク予想を超えるようなアクセスが現実に起こる可能性が高くなっています。こうした状況では、あらかじめ余裕を持たせて物理メモリ量の何掛けかで使用メモリ量を予想していても、そこを一瞬でも超えたらアウトです。しかも何度もいっているように、現実の運用では非常に複雑な要素が絡み合って限界まで稼働するエンタープライズシステムでは、「これこれだから、こうすればOK」といった単純な解はありません。私自身、ケースごとに微妙なノウハウを駆使してはいますが、それでも動かしてみるまでは分からないことだらけです。
だからといって、「仕方ない」で済ませてはプロとはいえません。一般に「Buffer Cache」のサイズはデータベースの物理サイズの1?2割が適正という人もいます。すでにそうした目安を用いて見積もることもできるのですから、まして、メモリの総和を算出して、なおかつ物理メモリをはじめとしたハードウェアの余力もきちんと計算していけば、限りなく正解に近い値は求められるはずです。
そんな難しいことを自分で分析するだけの知識がないという人は、第1回で紹介したような専用ツールを活用してください。もちろん腕に自信のある方でも、信頼できるツールを使って客観的に正確なデータを取ることは、適切なメモリ管理を行ううえで非常に有効です。
ミッションクリティカルなシステムでは合理的な考え方が大事
「メモリ管理は難しい」「細かいところは分からない」と初めからあきらめてしまわずに、今回お話ししてきたような概念をきちんと理解して、「自分のところのシステムでは、どのオブジェクトに対してどれくらいのメモリ領域を確保しておくべきなのか」を知るのが大切です。パフォーマンス・チューニングというと、経験や勘に頼った職人芸のように思われがちですし、事実そういう微妙な経験値がものをいう世界ではありますが、決して勘だけに頼っていてできるものでもありません。
やはり技術である以上は、科学的な思考と客観的な数値によって裏付けられるものだということを知ってください。ミッションクリティカルなシステムになるほど、ここをきちんと押さえておかないとダメです。このことを突き詰めていけばいくほどに、いかにメモリの問題が重要であり、なおかつ軽く考えると怖いものであるかが理解できるはずです。
システムテーブルを参照して、詳細な情報を視覚化しよう
せっかくの機会ですから、今回はSQL Serverのパフォーマンス・チューニングに威力を発揮する“裏技”をお教えしましょう。SQL Server 2000の「master」システムデータベース内にあるシステムテーブルの中に、「sysperfinfo」という名称のテーブルがあります。ここには、Windows OSのシステムモニタ(Windows NTではパフォーマンスモニタ)が参照しているSQL Serverの内部パフォーマンス・カウンタが格納されています。この“拡張版パフォーマンスモニタ”ともいうべきデータを参照することで、一般には非公開と思われている多くのパフォーマンス情報を見ることができるのです。SQL Server 2005では、「sysperfinfo」は「master」システムデータベース内のシステムビューになっています。これはリスト1のSQL文で参照できます。
SELECT * FROM sysperfinfo
このシステムテーブルを参照することで、「チェックポイントがいくつ発生しているか」とか、「SQLのコンパイルが秒当たりどれくらい行われているか」……といった細かなデータを見ることができます。実際に使ってみると、1回のSELECT文の実行で、通常のパフォーマンスモニタでは見られない、驚くほど詳細なデータが見られるはずです。慣れてくれば、パフォーマンスにかかわるトラブルの原因を探るときに、「ここがクサい」と思った場所を「sysperfinfo」で絞り込んでいくことも可能です。
ちなみにサードパーティ製のパフォーマンス監視ツールは、この「sysperfinfo」からデータを取得して、独自に演算した結果をGUIで見せています。それほどに役立つデータが「sysperfinfo」から得られるのだということです。
さて、駆け足で見てきましたが、実はSQL Serverのメモリ管理は、このテーマだけで本が1冊書けてしまうほど奥深いものです。私自身、いくら説明してもし切れないもどかしさがありますが、この記事を読んだ皆さんにも、ぜひ自分から興味を持って調べていただきたいと思います。(次回へ続く)
監修者プロフィール
株式会社CSK Winテクノロジ 執行役員 兼 技術推進担当。
熊澤 幸生(くまざわ・ゆきお)
メインフレーム環境で20年近くデータベース関連のITプロジェクトを数多く経験。また1979年から1983年まで米国に駐在し、データ主導型システム設計を実プロジェクトで学ぶ。1994年、アスキーNT(現、CSK Winテクノロジ)設立に参加し、SQL Server Ver 4.2からSQL Server 2000までシステム構築、教育にかかわってきた。現在同社執行役員 Chief Technology Officer。また、SQL Serverユーザー会「PASSJ」の理事として活動中。
- キャッシュを無駄遣いしないようにクエリを書く
- 64ビット時代の「バランスド・システム」
- DB管理者がいますぐ確認すべき3つの設定
- 内部動作を知らずしてチューニングは語れない
- CAT秘伝、バランスド・システムの考え方
- パフォーマンスを語るために歴史を語ろう
- チューニングに大変革をもたらす動的管理ビュー
- SQL Server 2005でガラッと変わった個所とは?
- チューニングとは……スレッドとの格闘に尽きる
- 進化するCPUをパワー全開で走らせるテクニック
- I/Oボトルネックの病巣はこれで究明できる
- I/Oチューニングを成功させる必修ポイント
- 排他制御の落とし穴を避けるインデックス設計
- 排他制御メカニズムから“待ち”原因を究明する
- パフォーマンスを満たす物理メモリ量を算出する
- 誰も知らないメモリ・チューニングの極意を教えよう
- SQL Serverというブラックボックスを開いてみる
Copyright © ITmedia, Inc. All Rights Reserved.