SQL Serverが一時的にログインできない（処理遅延）：SQL Serverトラブルシューティング（68）（1/2 ページ）

本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。今回は「SQL Serverが一時的にログインできない」場合の解決方法を解説します。

[内ヶ島暢之，＠IT]

SQL Serverトラブルシューティング一覧

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

トラブル 57（カテゴリー：処理遅延）：SQL Serverが一時的にログインできない

目次

• トラブルの実例
• トラブルの原因
• 解決方法

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します（本トラブルシューティングの対応バージョン：SQL Server 全バージョン）。

トラブルの実例：トランザクション量の多い大規模システムを長年運用している。時折アプリケーションのログインの失敗やクエリ実行の失敗が起きるようになった。業務量が増えていることは分かっており、現在のリソース量でしばらく耐えられるのかどうかを見極め、現在計画している移行の時期を早めなければならないのか、判断したいと思っている。

トラブルの原因を探る

　今回の現象のポイントはどんどん業務量が増える、つまりユーザーやトランザクション量が増えることにあります。この観点でパフォーマンスログを確認しました。CPU利用率は上がってきているものの、ボトルネックになっている様子はありませんでした。Page Life Expectancyは高い値を示しており、メモリ不足はなく、I/Oにも顕著なCurrent Disk Queue Lengthの増大は見られませんでした。

　次に幅広く取ってあったパフォーマンスログをじっくり端から端まで見たところ、図1のようなパフォーマンスログを発見し、値が高くなっている前後でエラーが出ていることが分かりました。

図1　Process: Thread Countのパフォーマンスログ
SQL Serverプロセス内でスレッド数が増加していることが分かる。

　「エラーが出力された時間帯でパフォーマンスの傾向が変わったところがあれば、明確な理由付けがなくとも仮説を立てる。さらにその仮説が原因となるシナリオが成立するかどうか検証する」。これがトラブルシューティングのコツです。

　SQL Serverは1つのプロセス内で複数のスレッドが動くプログラムです。ユーザーリクエストや内部処理はタスクという内部処理単位に分割され、ワーカースレッド（worker threads）と呼ばれる内部で生成されたスレッドが対応します。

　SQL Server内部でスレッドやタスク管理をするコンポーネントを「SQL OS」と呼びます。ここではSQL OSがワーカースレッドの増減を制御していることが重要です。ワーカースレッドを制御するパラメータはmax worker threadsです（図2）。

図2　max worker threadsの管理画面
0に設定した場合は、CPUに応じた規定値が適用される。なお、赤枠の直下にある「SQL Serverの優先度を上げる」「Windowsファイバーを使用する（簡易プーリング）」の設定はしない方がよい。設定するとWindows OS上でのSQL Serverスレッドの扱いが変わるため、システムスレッドが応答できなかったり、クラスタがフェイルオーバーしたりするなど、予期せぬ障害を招くことがある。

　今回の現象が起こった理由は、ワーカースレッドの数が要求数に対して不足していたためだと考えられます。ワーカースレッドが不足すると、次のような現象が起きることがあります。

• ログインの失敗
• クエリ実行の失敗
• FCI（Failover Cluster Instance：フェイルオーバークラスタインスタンス）環境の監視失敗によるフェイルオーバー
• ミラーリング環境におけるフェイルオーバー

　ワーカースレッドは処理数の増加や並列処理の実行の際に増加する傾向があります。

目次に戻る