SharePoint ブロッキング問題の調査手法 (前編)
| <連載>SharePoint ブロッキング問題の調査手法 (前編)SharePoint ブロッキング問題の調査手法 (後編) |
こんにちは。SharePoint サポートチームの荒川です。
以前に「SharePoint と SQL ブロッキングの話」と題して SharePoint Server におけるブロッキング問題について解説しましたが、今回は SharePoint ブロッキング問題の調査手法について、より実践的な内容に踏み込んで解説したいと思います。
はじめに
お客様からお問い合わせいただくパフォーマンス問題の大半を占める問題として SQL Server のブロッキング問題が挙げられます。ブロッキングとデッドロックは異なるもので、デッドロックはエラーとして検出されすぐにクライアント側にエラーが返されますが、ブロッキングは単に処理に時間がかかっている場合に発生する待ち状態になります。従ってプログラム上は正常に動作している範疇にあるものと捉えますので、これを「問題」ととらえるか否かは、ブロッキングの程度とユーザーの許容範囲に依るものとなり、その性質が、トラブルシュートをより難しいものにしています。
私の経験上、ブロッキングが発生する環境では同一コンテンツ データベース内に複数のサイト コレクションが存在し、さらに一部のサイトコレクションのデータ テーブルに数万件単位の大量のレコードが存在することが多いように見受けられます。レコードの内容は単純にリストやライブラリのアイテム数であったり、ユーザー権限や監査ログ等に関するレコードであったり、個人用 Web パーツやリンク情報といったユーザーの運用方法に大きく依存するため、一様にお伝えすることができないのが現状です。特にユーザーのアクセス毎にデータを登録したり、バッチ処理で大量のデータを処理するなどカスタマイズによる自動化が組み込まれた環境において発生しやすい傾向に感じます。
今回は私の検証環境を用いて実際に SharePoint 上でブロッキングが発生する状況を作り出し、その環境下で原因の特定を作業を進めていきますが、大規模なブロッキングを起こすようなデータ状態をすぐに再現することは難しいため、シンプルにブロッキングの調査手法をご理解いただくことを目的として、以下のような検証環境を作成してみました。
- SharePoint Server 2013 SP1 オールインワン (SQL を含む) 環境
- 検証用リストにフォルダーを作成
- フォルダー配下にアイテムを10万件登録
この環境で試しにルートフォルダーのリネームを実施したところ、およそ 40 秒程度の時間を要し、その間に別の IE ウインドウから該当フォルダー配下のアイテムのリネームを実施したところ、フォルダーのリネーム処理が完了するまでの間アイテムのリネーム処理が待たされる (ブロッキングされる) 状況を作り出すことができました。あまり頻繁に発生するようなシナリオではないかもしれませんが、ブロッキング調査の方法を理解するためのサンプルシナリオとして採用しています。
問題がブロッキングに依存するものかどうかの判断基準
ブロッキング問題にはサイトのパフォーマンスが若干低下する程度のものから、サイトに全くアクセスできなくなるものまで様々な程度があります。
パフォーマンスが一時的に低下するだけであれば、致命的な問題とはならず、エンドユーザーからの問い合わせも発生しない場合もありますが、重度なものでは長時間にわたりサイトに全くアクセスができなくなるなど致命的な問題に至る可能性もあります。
ブロッキング問題の特徴として、以下が挙げられます。
- 最初はいきなりエラーにならず、サイトが表示されるまで長い時間待たされ、最終的にタイムアウトエラーになったり、いつまでたっても砂時計のままサイトが表示されなかったりする
- ある日突然発生するが一度発生しだすと定期的に再発することが多い
- ユーザーアクセス数が多い環境では後続の接続が次第に溜まり続け、最終的に接続プールが枯渇して以降すべての接続がエラーになる
ブロッキングに起因するこれらの問題は多くの場合、Web サーバー全台の IIS リセットや、SQL Server サービスの再起動、フェールオーバーを行うことで解消されます。これは、最初のブロッキング要因となった処理がキャンセルされるためです。これらの特徴からブロッキング問題が疑われる場合には、まずその問題が本当にブロッキングに起因するものか特定し、ブロッキングに起因すると判断される場合はブロッキングの要因となった処理を特定して回避策の有無を調査することになります。
調査に必要な情報
ブロッキング問題は通常の SharePoint 関連の問題とは異なり、SharePoint と SQL Server 双方での情報採取が不可欠となります。SQL Server でブロッキングが発生した場合、SharePoint では単純にクエリの実行に時間がかかっているだけであると判断して SQL Server でのクエリの実行結果を待ち続けます。この動作は想定されたものであり、エラーとしては認識されません。クエリに時間がかかった場合は診断ログにおいて時間がかかっているクエリがあることを知らせる警告は出力されますが、このような警告は通常の運用においても発生する可能性があるものですので、SharePoint 関連のログを見ただけではブロッキングの有無を一様には判断できません。最終的にブロッキングが長時間におよび、後続の処理がタイムアウトした場合はタイムアウト エラーが返されることもありますが、SQL Server 側でどのようなことが起こりブロッキングが発生したのかは、SQL Server 側の情報を採取しなければ判断できないのです。
ブロッキング関連の問題を特定するには、以下の情報が必要となります。
- SharePoint 側の処理を確認するための情報
- 診断ログ
- IIS ログ
- メモリ ダンプ
- SQL Server 側の処理を特定するための情報
- 利用状況モニターの情報
- ブロッキングを引き起こしているセッション情報
- ブロッキングの原因となったクエリ情報
なお、注意点として、ブロッキングに関する情報は、既定の設定ではログに出力されません。
ブロッキング問題は、ブロッキングが発生している最中に、然るべきログを採取することで初めて特定できる問題になることに注意が必要です。
問題発生時にリアルタイムでブロッキングが発生しているか調べる方法
実際に運用環境においてブロッキングの可能性が考えられる問題が発生した場合、以下の方法でブロッキングの有無を調べることができます。
// Management Studio 利用状況モニターによるブロッキングの先頭プロセスの特定
1) Management Studio を起動し、対象の SQL Server インスタンスに接続します。
2) オブジェクト エクスプローラーでサーバー名を右クリックし、[利用状況モニター] を選択します。
3) 利用状況モニターが右ペインに表示されるため、その中の [プロセス] をクリックして展開します。
4) 列 [ブロック元] に数字が表示されている行の [セッション ID] がブロッキングされているプロセスです。ブロック元になっているセッション ID は該当行の [ブロック元] から確認できます。ブロック チェーンの先頭ブロックを特定するには [先頭ブロック] に 1 が表示されているセッション ID を探します。先頭ブロックが 1 になっているレコードの待機時間に注目し、問題が発生している期間中この値が増加し続けている場合は、該当のセッションの処理が原因でブロッキングが発生している可能性が考えられます。
// 先頭ブロックのセッションの接続元情報の特定
5) 引き続き Management Studio でツールバーから [新しいクエリ] を選択します。
6) 以下のクエリを貼り付けます。
| SELECT * FROM sys.dm_exec_sessions WHERE session_id = <先頭ブロックのセッションID> |
7) [!実行] ボタンをクリックしてクエリを実行します。
host_name および host_process_id に着目します。host_name が接続元のサーバー名、host_process_id がそのサーバー上で動作するプロセスの PID です。この後、該当サーバーのタスクマネージャでプロセス ID から原因となっているプロセスを特定することになりますが、SharePoint のプロセスが原因でブロッキングが発生している場合、殆どのケースでは w3wp.exe になるかと思います。
ここまで特定できた場合、問題の回避を優先するのであれば対象のサーバーで IIS リセットを実施すれば先頭ブロックは解放されるため事象は解消されると考えられますが、事象が解消してしまうとブロッキングの根本原因の特定が困難になるため、再発防止策を含めた調査が必要になるのであればさらに詳細な情報採取を行う必要があります。
後編では、ブロッキングの要因となった操作を特定する方法について解説します。