ここからはじめる SQL Server の状態取得

ここからはじめる SQL Server の状態取得

小澤真之 (@Masayuki_Ozawa)

自己紹介

2

SQL Serve 関連の案件を中心に仕事をしていけるといいなと考えているフリーランスのエンジニアです。

SE の雑記というブログをやっていますhttp://blog.engineer-memo.com/

SNS はこちら Twitter :

@Masayuki_Ozawa Facebook : http://www.facebook.com/masayuki.ozawa

2012/12/01SQLSaturday #181

http://blog.engineer-memo.com/

http://blog.engineer-memo.com/

現状取得の重要性


突然こんなこと言われたことがありませんか？？

最近サーバーが遅くなった気がするんだけど、どうして？？

どうして突然遅くなった？？


データが増えた？？利生者数が増えた？？インデックスの断片化？？統計情報が古くなって最適な実行プランではない？？

そもそも、遅くなったって何と比較して？？感覚値との比較？？

サーバーの使用状況の変化を把握することで何があったかを確認することが重要 !!

レスポンス悪化時の問題解決の 2 つのアプローチ


二つのアプローチ


• クエリの実行プランの最適化• インデックスチューニング• ロックの最適化　……

クエリ最適化 ( 部分最適 )

• ハードウェアリソースの使用状況の最適化• CPU / ディスク / メモリ / ネットワーク• 待ち事象 (Wait Stats / Latch Stats) ……

サーバー最適化 ( 全体最適）

処理が遅い画面が分かっている

全体的 / なんとなく遅い

今回の内容

ここからはじめてみてはどうでしょう


基本情報を取得するからはじめてみる


リソースの基本情報を正しく取得 / 整理するところから、はじめてみてはどうでしょう。

サーバーの基本的なリソースCPUディスクメモリネットワーク

　　このグラフをどう見ますか？？

9

以下のようなディスクの使用率のグラフがあります。ディスクがボトルネックになっているでしょうか ?

Disk Read が頻繁に発生

Disk Queue が頻繁に発生

Disk Write は定期的に発生

Logical Disk : Current Disk Queue LengthLogical Disk : Avg. Disk Bytes/ReadLogical Disk : Avg. Disk Bytes/Write


ボトルネックになっているのは？？

2012/12/01SQLSaturday #18110

1. ディスクのスペックが不足している

2. CPU のスペックが不足している

3. メモリのサイズが不足している

4. わからない

私の回答はこれ

各リソースの情報をどう読む ?

11

CPU サーバー全体の CPU の使用率 SQL Server のプロセスの CPU の使用率コンパイル / リコンパイルの発生状況 CPU キュー

メモリサーバーの使用可能な空きメモリ SQL Server のメモリ使用状況キャッシュヒット率

ディスクディスク読み込み / ディスク書き込み ( ディスクキュー )

ネットワーク受信バイト / 送信バイトネットワークキュー


キホンのキホン

2012/12/01SQLSaturday #18112

瞬間値や平均値ではなく時系列にデータを整理する瞬間値 ( 最大値 ) は有効なデータになりえます？？

瞬間的に 100% に達するのは問題でしょうか ?? リソースを有効に使っているという見方もできます。

リソースの使用状況を波形で見れるようにするのが重要 100% に張り付いた状態が継続していないことを確認ピーク時間とオフピーク時間のリソースの使用状況を確認

複数のリソースの情報を組み合わせて確認する一つのリソースだけで判断しないことがポイント

先ほどわからないといった理由はこれ

たとえばこのようなことが考えられます

2012/12/01SQLSaturday #18113

ディスクディスクの書き込みではなく読み込みの頻度が多い

→ ディスク / メモリがボトルネックになりえる CPU

ユーザーが増えたことにより再利用されない SQL が頻繁に実行され、コンパイルの発生が頻発し CPU が 100% になっている→ CPU / メモリがボトルネックになりえる

メモリデータの増加によって、メモリが不足して頻繁にデータがディスクから読み

込まれている→ メモリ / ディスクがボトルネックになりえる

使用するツール

2012/12/01SQLSaturday #18114

現状を見るために使用するツール

15

SQL Server 2000 Undocumented DBCC システムテーブル OS のパフォーマンスモニター

SQL Server 2005 動的管理ビュー (DMV) SSMS の標準レポート SQL Server 2005 Performance Dashboard Reports

SQL Server 2008 / R2 / SQL Server 2012 データコレクション ( ただし、 Enterprise Edition)

SQL Server 2008 以降は SQL Server の機能でパフォーマンス状態のレポートが作れるようになりました

拡張イベント (XEvent)

今回はこれ

これも少し


データコレクションの画面例

16 2012/12/01SQLSaturday #181

パフォーマンスモニタとは？？

17

リアルタイムのパフォーマンス情報現状を確認するときに使用します

パフォーマンス情報のログの取得ベースラインを作成するときに使用します

リモート (別のコンピュータ ) からも取得できますサーバーのディスク容量が無くても別のコンピューターにログを取得できます

SQL Server 固有のカウンタならメモリの情報を取得できますタスクマネージャーでメモリの使用状況が取得できなくても、 SQL Server 固

有のカウンタからはメモリの使用状況を取得することができます。


エディションに依存せずに使用できるので

どの環境でも情報を取得可能

18

データ取得時の環境例モニタリング端末

PerflogUser(Performance Log User)(Performance Monitor

User)

モニター対象

PerflogUser(Performance Log User)

(Performance Monitor User)

ログ取得ディレクトリ別端末から取得

同一ユーザー名 / 同一パスワード( ワークグループ環境のため )


パフォーマンスモニタで取得する項目の例

19

「 SQL Server Perlman Counters Poster」でビングってください Quest Software さんから SQL Server のパフォーマンスモニタのカウン

タについて、まとまった情報が公開されています


最初にすること

2012/12/01SQLSaturday #18120

こういうデータを見ていませんか？

21

最大 / 最小 / 平均を表にする

タスクマネージャーで確認

CPU Memory

最大最小平均最大最小平均9:00 50% 10% 40% 10GB 10GB 10GB

10:00 90% 10% 80% 10GB 10GB 10GB

11:00 96% 15% 90% 10GB 10GB 10GB

sqlservr.exe の状態を確認


データの読み方

22

4 つのポイント

1. 波形を見る2.同じ種類の複数の情報を重ねる3.違う種類の情報と比較する4. 比率を見る


波形を読む

23

波形からCPU 使用率の高い時間を把握

Processor : %Processor Time (_Total)


ピークタイム (高負荷 ) とオフピークタイム (低負荷 )

の状態を確認する

同じ種類の複数の情報を重ねる

24

Processor : % Processor Time (_Total) Process : % Processor Time (sqlservr)

プロセッサの使用率の波形とSQL Server のプロセスの

波形が一致


SQL Server のプロセスがCPU を多く使用している

ことが読み取れる

違う種類の情報と比較する

25

Buffer Manager : Buffer Cache Hit RatioPlan Cache : Cache Hit RatioBuffer Manager : Page life expectancy

データのキャッシュヒット率メモリが不足していると低い

クエリのキャッシュヒット率アドホッククエリが多いと低い

メモリ内のデータでどの程度の時間処理ができているか

300秒以上が一般的な推奨値


どの用途のメモリが不足しているかを確認

比率を見る

26

SQL Server の使用メモリ

サーバー上の空きメモリ

SQL Server 以外の使用メモリ

Memory : Available MBytesProcess : Working Set (sqlservr 以外 )Memory Manager : Total Server Memory (KB)


全体のメモリに対してどの程度使用しているか

SQL Server のメモリ構造

27

Buffer Manager : Database Pages

Plan Cache : Cache Pages

Memory Manager : Connection Memory (KB)

Memory Manager : Granted Workspace Memory (KB)

Memory Manager : Lock Memory (KB)

一時利用

キャッシュ


一歩踏み込んでメモリの状態を確認

28

プロシージャキャッシュ

Buffer Manager : Free pagesBuffer Manager : Database PagesPlan Cache : Cache Pages (_Total)※各値はページ数なので 8KB をかける※SQL Server 2012 ではカウンタ名少しが変わっています

データキャッシュ


フリーページ

SQL Server が確保しているメモリでも内部的には

空きがあることが

DMV でさらにブレークダウン

29

データキャッシュの詳細は [sys].[dm_os_buffer_descriptors] で

プロシージャキャッシュの詳細は [sys].[dm_exec_cached_plans] で


DB 単位のメモリの使用状況を取得

用途単位でメモリの使用状況を取得

最初のグラフを改めて見直すと

30

Disk Read が頻繁に発生

Disk Queue が頻繁に発生

Disk Write は定期的に発生

Logical Disk : Current Disk Queue LengthLogical Disk : Avg. Disk Bytes/ReadLogical Disk : Avg. Disk Bytes/Write


組み合わせると見えてくる !!

31

データキャッシュのヒット率が低いとディスクからデータの読み込みが発生しているので、ディスク負荷が高くなる傾向に

プランキャッシュのヒット率が低いとコンパイルの発生回数が多くなるため、 CPU 負荷が高くなる傾向に

ディスク / CPU の値が高くてもメモリネックの場合があります。

このような場合は、違う種類の情報を比較することが重要です。


使い分けが重要

32

パフォーマンスモニタは現状を俯瞰するのが得意です各カウンターで現状を取得して、特異点があれば DMV でブレークダウン

DMV は現状の状態詳細に取得するのが得意です DMV の情報はサービスを再起動すると初期化されるのでログとして取得す

る場合はユーザー定義のデータコレクションまたは、定期的にクエリを実行してテーブルに格納することで対応

拡張イベントはイベントを取得するのが得意です今回は紹介できていませんが拡張イベントでは内部動作を取得できます。セッション単位の待ち事象 (Wait Stats / Ratch Stats) ブロッキング ( ロックの競合 )


33

基本的な情報の組み合わせで

有効な情報がとれる !!2012/12/01SQLSaturday #181

さらに踏み込みたい方は

2012/12/01SQLSaturday #18134

実行状態の遷移

2012/12/01SQLSaturday #18135

実行状態(RUNNING)

実行可能状態(RUNNABLE)

待機状態(SUSPENDED)

処理を実行している状態CPU

メモリディスク

処理を待機している状態ロック

並列処理同期ディスク I/O

待機がなくなり処理の開始待ちCPU 使用権の譲渡

キューの解放

待機状態の理由を考える

2012/12/01SQLSaturday #18136

実行状態が長い = 処理に時間がかかるどの処理で時間がかかっているかを確認実行プランのイテレータを確認 sys.dm_exec_requests ( 実行中の要求 ) で確認することができます。

待機状態が長い = リソースを使用できる状態になるのに時間がかかるどのリソースを使用可能な状態になるのに時間がかかっているかを確認 sys.dm_os_wait_stats ( 待機の累計 ) で確認をすることができます。

最初の一歩は利用状況モニターから

2012/12/01SQLSaturday #18137

詳しく知りたい方はこちらを

2012/12/01SQLSaturday #18138

SQL Wait Stats Joes 2 Pros: SQL Performance Tuning Techniques Using Wait Statistics

まとめ

39

パフォーマンスモニターの勘所がわかれば状態取得ははじめられますインデックスチューニング / DMV 詳細確認は難しいかもしれませんが、基本的な

情報を取得して整理するところからはじめてみてはどうでしょう。

取得したデータを読むときは単純な値を控えるのではなく波形や複数の情報を組み合わせることが重要になってきます組み合わせることで見えてくる事象があります。

定期的にベースラインと現状を比較し、負荷があがっているかを判断するのが予防保守として重要になってきますベースラインを作成したら終わりではなく定期的にベースラインとの比較をするの

が大事です急に遅くなっていないことを証明するための予防線


Documents

ここからはじめる SQL Server の状態取得