待ち事象から考える、Sql server の改善ポイント

待ち事象から考える、 SQL Server の改善ポイント
小澤真之
Microsoft MVP for SQL Server (July 2011 -June 2015)
D11

自己紹介
2 db tech showcase 2014
フリーランスエンジニアとしてSQL Server の案件を中心に従事しています
案件等で協力できることがありましたらお声掛けいただけると幸いです
「SQLServer現状診断」によるSQLServer稼働状況の報告書作成
「SQL Server 性能情報解析手法の基礎」のセミナー実施
Microsoft MVP for SQL Server (July 2011 -June 2015)
コミュニティやブログでSQL Server の情報を発信
コミュニティ活動
SQL Server : SQLTO (http://sqlto.net)
Azure : JAZUG(http://r.jazug.jp/)
ブログ: SE の雑記(http://engineermemo.wordpress.com)
2014/11/11

本セッションについて
本セッションでは、SQLServerの基本的な待ち事象についての理解し、今後の改善ポイントを策定するための、基本的な知識の取得を目的としています。
本セッションの内容はSQL Server 2014 をベースとしていますが、一部の内容を除いて2005 ～2012 でも利用することが可能です。
2014/11/11

最適な処理の実行とは??
4 db tech showcase 2014 2014/11/11
データベースで、最適な処理の実行状態とは？？
実行した結果が瞬時に取得できる
待ちが発生せずに結果を取得

待ち事象の概要

一般的な処理のライフサイクル
実行状態 (RUNNING)
実行可能状態 (RUNNABLE)
待機状態 (SUSPENDED)
待ち事象が発生している

SQLServerの待ち事象の種類
Wait Stats
Latch Stats
Spinlock Stats
本セッションの内容

待ち事象の取得方法

待ち事象を取得する方法
パフォーマンスモニター
動的管理ビュー
拡張イベント

パフォーマンスモニター
SQLServer:WaitStatistics オブジェクトから取得可能
http://msdn.microsoft.com/ja-jp/library/ms190732.aspx
一部の待ち事象を時系列で取得することができる
Lock waits
Log buffer waits
Log write waits
Memory grant queue waits
Network IO waits
Non-Page latch waits
Page IO latch waits
Page latch waits
Thread-safe memory objects waits
Transaction ownership waits
Wait for the worker
Workspace synchronization waits

動的管理ビュー1/2
sys.dm_os_wait_statsから取得可能
http://msdn.microsoft.com/ja-jp/library/ms179984.aspx
SQL Server 2014 では770 程度の待ち事象の情報を取得可能
SQLServerのサービスが最後に起動してからの累計値を格納
動的管理ビュー
項目
Lock waits
LCK_M_xx
Log write waits
WRITELOG
Network IO waits
ASYNC_NETWORK_IO
Page IO latch waits
PAGEIOLATCH_xx
SOS_SCHEDULER_YIELD

動的管理ビュー2/2
以下の情報を取得可能
waiting_tasks_count
wait_time_ms
max_wait_time_ms
signal_wait_time_ms
wait_time_msとsignal_wait_time_msの比率にも注目
T0 : リソースの要求
T1 : シグナルの受付
T2 : リソースの利用開始
Signal Wait Time (ms)
Wait Time (ms)

拡張イベント
SQL Server 2008 から利用することができるようになった軽量なパフォーマンス監視システム
SQLServer2012からSSMSで容易に設定可能
セッションごとにsys.dm_os_wait_statsの情報を取得できる
wait_infoまたはwait_completedイベントから取得可能
duration : wait timems
signal_duration: signal wait ms

DEMO
待ち事象の取得

リソースの待ち

ディスク
リソースの待ち1/2
アプリケーション
データファイル
ログファイル
CPU
SQL Server
メモリ
2014/11/11

ディスク
リソースの待ち2/2
ログファイル
CPU
SQL Server
メモリ
ASYNC_NETWORK_IO
WRITELOG
アプリケーション
SOS_SCHEDULER_YIELD
PAGEIOLATCH_xx
2014/11/11

待ち事象とリソースの関係
リソース
待ち事象
要因
ネットワーク
ASYNC_NETWORK_IO
クライアント(アプリケーション) がサーバーからのデータを処理
CPU
SOS_SCHEDULER_YIELD
他のタスクの実行にスケジューラーを解放
メモリ (ディスク)
PAGEIOLATCH_xx
I/O要求でバッファーラッチが待機
ディスク
WRITELOG
ログフラッシュの完了を待機

待ち事象の見方
待ち事象が発生している= リソースが不足している
ではない
性能以上の待ち事象が発生しているのが問題
リソース
考慮点
ネットワーク
クライアント/サーバーの帯域上限に達した状態を推移している
ネットワークキューが頻繁に発生している
CPU
CPUの使用率が100% に達した状態を推移している
CPUキューが頻繁に発生している
メモリ
キャッシュのヒット率が低い
ディスクからの読み取りに時間がかかっている
ディスク
ディスクからの読み取りに時間がかかっている
ログの書き込みに時間がかかっている

パフォーマンスモニターとの対比
パフォーマンスモニターと待ち事象を対比し、リソースの使用状況を把握
待ち事象
ASYNC_NETWORK_IO
NetworkInterface¥BytesRecived/sec
Network Interface¥Bytes Sent/sec
Network Interface¥Bytes Total/sec
Network Interface¥Output Queue length
SOS_SCHEDULER_YIELD
Processor¥% Processor Time
Process(sqlservr)¥%Processor Time
System¥Processor Queue Length
SQLServer:SQLStatistics¥Batch Request/sec
PAGEIOLATCH_xx
Logical Disk (Physical Disk)¥Current Disk Queue Length
Logical Disk (Physical Disk)¥Disk Read/ Write Bytes/sec
Logical Disk (Physical Disk)¥Disk Read/ Write /sec
SQLServer:BufferManager¥Buffer cache hit ratio
SQLServer:BufferManager¥Page life expectancy
WRITELOG
SQLServer:Database¥LogFlush Waits/sec

CPU に関連する待ち

CPUで処理できる上限
CPUが瞬間的に実行できるのは一つの処理
CPU
処理A
処理B
処理A
CPU
スケジューラーの譲渡が発生する
SOS_SCHEDULER_YIELD

待ち事象
ASYNC_NETWORK_IO
SOS_SCHEDULER_YIELD
PAGEIOLATCH_xx
WRITELOG

DEMO
SOS_SCHEDULER_YIELDの確認

CPU の利用時間
CPUを長い時間使用しているクエリに注目
CPU時間(Worker Time/ CPU Time)
クエリの実行時間(Elapsed Time)
CPU時間の長いクエリは以下から調査可能
プランキャッシュから取得
sys.dm_exec_query_statshttp://msdn.microsoft.com/ja-jp/library/ms189741.aspx
実行中のセッションから取得
sys.dm_exec_sessionshttp://msdn.microsoft.com/ja-jp/library/ms176013.aspx
利用状況モニター

クエリのコンパイル
クエリの初回実行時にはクエリのコンパイルが行われる
クエリのコンパイルに使用されたリソースは実行プランから取得可能
CompileTime(ms)
CompileMemory(KB)
CompileCPU(ms)
http://schemas.microsoft.com/sqlserver/2004/07/showplan
過度なコンパイルの実行はCPUの負荷上昇にもつながる
ストアドプロシージャ/ パラメーター化されていないクエリの大量の実行
類似のアドホッククエリの大量キャッシュはコンパイルコストが高い
SELECT* FROM Table_1 WHERE Col1 = ‘AAAAA’
SELECT* FROM Table_1 WHERE Col1 = ‘BBBBB’

DEMO
CPU改善のためのクエリ取得

メモリに関連する待ち

SQL Sever の基本的なメモリ構造
Memory Manager : Database Cache Memory (KB)
Plan Cache : Cache Pages
Memory Manager : Connection Memory (KB)
Memory Manager : Granted Workspace Memory (KB)
Memory Manager : Lock Memory (KB)
一時利用
キャッシュ
今回の対象

SQL Server のI/O
ディスク
ログファイル
CPU
SQL Server
メモリ
論理I/O
物理I/O
PAGEIOLATCH
どちらも
CPUを利用

待ち事象
ASYNC_NETWORK_IO
SOS_SCHEDULER_YIELD
PAGEIOLATCH_xx
WRITELOG

物理I/O を減らすためには
物理I/O の回数を減らす
Scan操作ではなくSeek操作による検索効率の改善
検索効率の改善による処理時間の短縮は、CPU使用率の改善にもつながる
読み取るページ数の削減
インデックスの断片化の解消
データの圧縮機能
行/ データ圧縮
列ストアインデックス
データのキャッシュ領域を有効に活用
キャッシュヒット率を上げる
プランキャッシュを減らすことでデータキャッシュの領域を増加
データ圧縮によりキャッシュできるページを増やす
圧縮されたデータは圧縮された状態でメモリにキャッシュされる
Enterprise Edition の機能

DEMO
論理I/O と物理I/O

ディスクの待ち

ディスクの基本性能を把握する
SQLServerのI/Oでディスクの基本性能を取得するためのツールを利用
SQLIO
SQLIO Disk Subsystem Benchmark Tool http://www.microsoft.com/en-us/download/details.aspx?id=20163
SQLIOSIM
C:¥Program Files¥Microsoft SQL Server¥<インスタンスID>¥MSSQL¥Binn
サーバーの構築が完了したタイミングで測定することを推奨
HD
SSD
1 スレッド
10スレッド
1 スレッド
10スレッド
8KB
64KB
8KB
64KB
8KB
64KB
8KB
64KB
Sequential
Read
IO/sec
8,240
2,753
16,270
3,851
7,362
2389
24,039
3,135
MBytes/sec
64
172
127
240
57
149
187
195
Write
IO/sec
8,752
2,512
17,728
3,859
7,625
1678
21,026
2,704
MBytes/sec
68
157
138
241
59
104
164
169
Random
Read
IO/sec
158
143
247
222
4,718
1920
18,322
3,049
MBytes/sec
1
8
1
14
36
119
143
190
Write
IO/sec
810
710
875
779
7,600
1,637
18,347
2,417
MBytes/sec
6
44
6
49
59
102
143
151
SQLIOSIM を使用したディスク性能の測定例

2 種類の待ちに注目
PAGEIOLATCH
データの読み取り
メモリに関する待ちと同じアプローチ
WRITELOG
データの書き込み

LogBuffer
ログの書き込みの基本動作
ディスク
ログファイル
CPU
SQL Server
メモリ
LogFlush
WRITELOG

待ち事象
ASYNC_NETWORK_IO
SOS_SCHEDULER_YIELD
PAGEIOLATCH_xx
WRITELOG

ログフラッシュの発生タイミング
DECLARE @cntint= 1
BEGIN TRAN
WHILE (@cnt<= 10000)
BEGIN
INSERT INTO WriteLogTestVALUES(NEWID())
SET @cnt+= 1
END
COMMIT TRAN
ログフラッシュ
ログレコードがディスクに書き込まれ完全持続性が保障される
ログフラッシュの完了を待たずに処理を完了させる→ 遅延持続性
DECLARE @cntint= 1
WHILE (@cnt<= 10000)
BEGIN
INSERT INTO WriteLogTestVALUES(NEWID())
SET @cnt+= 1
END

DEMO
WRITELOGの確認

まとめ
最初の一歩として、以下の待ち事象とパフォーマンスモニターを組み合わせることで全体的なリソースの使用状況を把握することができる
SOS_SCHEDULER_YIELD
PAGEIOLATCH_xx
WRITELOG
リソースの使用状況を把握することで改善ポイントを検討できる

待ち事象から考える、Sql server の改善ポイント

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 待ち事象から考える、Sql server の改善ポイント

Ähnlich wie 待ち事象から考える、Sql server の改善ポイント (20)

Mehr von Masayuki Ozawa

Mehr von Masayuki Ozawa (20)

待ち事象から考える、Sql server の改善ポイント