メモリ不足
これはメモリの問題である可能性が非常に高く、おそらく他の要因によって悪化または引き起こされますが、それでも本質的にメモリの問題です。他に 2 つの (可能性は低いですが) 可能性があります。最初にチェックして排除する必要があります (そうするのは簡単なので):
簡単にチェックできる可能性:
<オール> <リ>「自動クローズ」が有効になっている可能性があります。自動クローズはまさにこの動作を行うことができますが、オンになることはめったにありません。これを確認するには、SSMS でアプリケーション データベースを右クリックし、[プロパティ] を選択してから、[オプション] ペインを選択します。 「Auto Close」エントリを見て、False に設定されていることを確認します。 tempdb もチェックしてください。
<リ>SQL エージェント ジョブが原因である可能性があります。エージェントの履歴ログをチェックして、イベント中に一貫して実行されているジョブがあるかどうかを確認します。インデックスの再構築などは、実行中のパフォーマンスの問題として頻繁に挙げられるため、メンテナンス ジョブも忘れずに確認してください。通常はプロファイラーの影響を受けないという理由だけで、これらは今のところ候補にはなりません。
メモリの問題のように見える理由:
これらに何も表示されない場合は、メモリの問題を確認する必要があります。あなたの場合、次の理由からメモリが原因だと思います:
- <リ>
1 GB のメモリがあります:これは技術的には SQL Server の最小値を上回っていますが、SQL Server の推奨値をはるかに下回っており、負荷の軽いサーバーであっても、私の経験では本番環境で許容できる値をはるかに下回っています.
<リ>IIS と SQL Server を同じボックスで実行している:これは、主にメモリの競合が発生するため、単独では推奨されませんが、メモリが 1 GB しかないため、IIS、アプリ、SQL Server、 OS およびその他のタスクおよび/またはメンテナンスはすべて、ごくわずかなメモリを求めて戦っています。 Windows がこれを管理する方法は、非アクティブなプロセスからメモリを積極的に奪うことによって、アクティブなプロセスにメモリを与えることです。この状況では、SQL Server のような大規模なプロセスが十分なメモリを取り戻して、要求を完全に処理できるようになるまでに、数秒または数分かかる場合があります。
<リ>プロファイラーは問題の 90% を解決しました:これは、メモリが問題である可能性が高いという大きな手がかりです。なぜなら、通常、プロファイラーのようなものは、この特定の問題に対してまさにこの効果を持っているからです: 常に少しアクティブです。多くの場合、これは OS の「スカベンジャー」リストから除外するか、少なくともその影響をいくらか軽減するのに十分なアクティビティです。
原因となっているメモリを確認する方法:
<オール> <リ>プロファイラーをオフにする:問題にハイゼンベルグ効果があるため、オフにする必要があります。そうしないと、問題を確実に確認できなくなります。
<リ>別のボックスからシステム モニター (perfmon.exe) を実行し、SQL Server と IIS が実行されているボックスのパフォーマンス コレクション サービスにリモート接続します。これを最も簡単に行うには、最初に 3 つのデフォルトの統計情報 (ローカルのみ) を削除してから、必要な統計情報 (以下) を追加します。ただし、最初のドロップダウンでコンピューター名を変更して SQL に接続するようにしてください。ボックス。
<リ>perfmon で「カウンター ログ」を作成して、収集したデータをファイルに送信します。これに慣れていない場合、おそらく最も簡単な方法は、Excel で開いて分析できるタブまたはカンマ区切りのファイルにデータを収集することです。
<リ>ファイルに収集するように perfmon をセットアップし、次のカウンターをファイルに追加します。
-- Processor\%Processor Time[Total]
-- PhysicalDisk\% アイドル時間[各ディスク ]
-- PhysicalDisk\Avg.ディスク キューの長さ[各ディスク ]
-- メモリ\ページ/秒
-- メモリ\ページ読み取り/秒
-- メモリ\利用可能なメガバイト
-- Network Interface\Bytes Total/sec[使用中の各インターフェイス ]
-- Process\% Processor Time[以下を参照 ]
-- Process\Page Faults/sec[以下を参照 ]
-- プロセス\ワーキング セット [以下を参照 ]
<リ>プロセス カウンター (上記) には、sqlserver.exe プロセス、IIS プロセス、および安定したアプリケーション プロセスを含める必要があります。これは「安定した」プロセスでのみ機能することに注意してください。必要に応じて継続的に再作成されるプロセスは、存在する前に特定する方法がないため、この方法ではキャプチャできません。
<リ>問題が最も頻繁に発生する時間帯に、このコレクションをファイルに実行します。収集間隔を 10 ～ 15 秒に近い値に設定します。 (これにより多くのデータが収集されますが、個別のイベントを選択するにはこの解像度が必要になります)。
<リ>1 つ以上のインシデントが発生したら、収集を停止し、収集したデータ ファイルを Excel で開きます。おそらく、タイムスタンプ列を再フォーマットして便利に表示し、時間、分、秒を表示する必要があります。 IIS ログを使用してインシデントの正確な時間を見つけ、perfmon データを調べてインシデントの前後に何が起こっていたかを確認します。特に、以前はワーキング セットが小さく、その後は大きく、その間に多くのページ フォールトが発生したかどうかを確認する必要があります。これは、この問題の最も明確な兆候です。
解決策:
IIS と SQL Server を 2 つの異なるボックスに分けるか (推奨)、ボックスにメモリを追加します。最低でも 3 ～ 4 GB が必要だと思います。
その奇妙な EF はどうですか?
ここでの問題は、それが周辺的なものであるか、主な問題の唯一の原因である可能性が高いということです。 Profiler によってインシデントの 90% が解消されたことを思い出してください。 別の問題であるか、最も極端な悪化要因にすぎない可能性があります 問題の。その動作から、キャッシュを循環させているか、アプリケーション サーバー プロセスのバックグラウンド メンテナンスが行われていると推測できます。