インスタンスのパフォーマンスを維持するために定期的な再起動が必要なのはなぜですか？

SQL 2005に運用DBサーバーがあります。すべてはしばらく正常に動作しますが、数週間後、顕著なパフォーマンスの低下が見られます。SQL Serverを再起動するだけで、パフォーマンスが通常に戻ります。

背景：

• 1200以上のデータベース（ほとんどが単一テナント、一部がマルチテナント）を実行しています。マルチテナントのみへの移行について講義する前に、この構造を維持する正当な理由があります......
• RAMは16 GBです。再起動後、SQL Serverが15 GBの使用量に戻るのにそれほど長くかかりません。
• アクティブDB接続は約80の接続です-プロセスごとにWebサーバーごとに1つの接続プールがあることを考えると、かなり健全であると感じているため、接続リークの問題はありません。

ピーク時以外にいくつかのことを試しました。-DBCC DROPCLEANBUFFERS（チェックポイント付き）を実行して、データキャッシュをクリアします。効果はなく、RAM使用量もクリアされません）。-FREEPROCCACHEおよびFREESYSTEMCACHEを実行して、クエリプランとストアドプロシージャキャッシュをクリアします。無効。

明らかに、SQL Serverを再起動することは、アクティブな運用環境では理想的ではありません。何かが欠けています。他の誰かがこれを通過しますか？

更新：April-28-2012 まだこの問題と戦っています。OSとの競合を排除するために、SQL Serverのメモリを10 GBに下げました。絞り込みに近づいていますが、次のステップからの助けが必要です。

SQL Serverを再起動した後、ページファイルが12.3 GBから12.5 GBの間でホバリングしていることがわかりました。それは数日間そのままです。合計サーバースレッドは850から930の間でハングアウトします-安定しており、終日一貫しています（sqlserverはトラフィックに応じて55から85の間で安定しています）。

次に、「イベント」があります。私はイベントが何であるかわからず、ログでそれを見ることができず、曜日またはそれが起こる時間に一貫したものを見ることはできませんが、突然ページファイルはすべて14.1または14.2のいずれかにジャンプしますGB、およびスレッドは1750〜1785の間にジャンプします。

これが発生したときにパフォーマンスをチェックすると、これらのスレッドのうち900以上がsqlserverです。したがって、sp_who2にアクセスして、これらのスレッドがどこから来ているのかを確認します。使用されている80個程度のdb接続があります。

だから.... SQLサーバー上のこれらの900個のスレッドの残りがどこにあるのか、そして彼らが何をしているのかを見つけることができるアイデアはありますか？

更新：2012年6月1日 まだ問題と戦っています。まだこれを読んでいる人にとっては、スレッドが跳ね上がる問題は解決されています。これは、自動化されたComVaultバックアップソフトウェアが原因でした。現在のデータベースを単にバックアップするのではなく、もはや存在しないデータベースをバックアップしようとするスレッドを作成していました（以前のデータベースのリストを維持していました）。

しかし、問題はまだ残っており、毎週再起動する必要があります。Rackspaceチームと協力して、光を当てられるかどうかを確認します。

あなたはすべてがうまくいっていると言い、数週間後にパフォーマンスが低下します。（通常、パフォーマンスは急速に、または特定の時間に、または一見ランダムな間隔で低下すると主張します。これは、I / Oパフォーマンスの悪さ、ロックストーム、CPU集中クエリが頻繁に実行されること、または重いスケジュールジョブまたはCPUを集中的に使用するクエリやディスク読み取りなどを引き起こすインデックス作成や悪い統計。週は珍しいです。

私の仮説は、サーバー上の別のアプリケーションがメモリをリークしているということです。これは、ウイルスソフトウェア（DBAのお気に入りのサーバーソフトウェアの悪役）とサードパーティの監視ソフトウェアで見ました。時間の経過とともにSQL Serverのメモリ使用量を再確認し、ボックス上の他のすべてのアプリケーションのメモリ使用量もすべて取得します。SQL Serverのメモリ使用量にハード制限を設定し、ページングを許可しないように設定している場合、ページアウトされてI / O容量を消費しているのは他のアプリである可能性があります。

探すのは難しくありません。サーバー上のメトリックをまだ保持していない場合は、Perfmonを起動して、30分または60分ごとにサンプルを取得します。数日後、別のアプリケーションのメモリ使用量が徐々に増加することがあります。

「SQLサーバーの重要な部分がページアウトされた」というエラーメッセージがSQL Serverログにありますか？それも大きな手がかりになります。

わずか16 GBのRAMを備えたSQLサーバーの単一インスタンスで1200のDBを実行でき、数週間のスムーズな実行後にこれらのタイプの問題のみが発生したことを祝福します。地元のPASSの章で伝えるのはいい話です。

トラブルシューティング：SQLとOSの両方のRAMは16 GBです。最大メモリ設定が15 GBまたは最大であると仮定しています。これにより、バッファプールがすべてのメモリを使い果たし、OSを停止させる可能性があります。バッファプールとキャッシュをクリアしても違いは表示されず、PLEは300を超えていると言っています。これは、メモリのボトルネックを証明しています。サーバーのCPUとIOはどのようになっていますか（仕様/統計）。

実行select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidし、表示されるリソースの競合（wait_type、wait_time、last_wait_type、wait_resource）を確認します。

1200のデータベース、OS、そしておそらく他のもの？ええ、サーバー自体が機能するために1GB以上のRAMが必要になると思います。特に、SQL Serverの最大メモリ設定として15GBを設定すると、スレッド用に15GB 以外のメモリがさらに必要になることを考慮してください。

SQL Serverを14GBまで下げて、サーバーにもう少し余裕を持たせます。

また、16GB RAMを搭載したサードパーティバックアップユーティリティを備えたSQL Server 2008 x64システムでのメモリの許容量については、「Professional SQL Server 2008の内部とトラブルシューティング」に記載されている例もあります。

• Windows用に2 GB
• ワーカースレッド用に1GB
• MPAなどの場合は1GB
• バックアッププログラム用に1GB
• SQL Serverの場合は11GB

この本では、所有できるスレッドの最大数を決定する方法と、それらが占有するメモリ量を計算する方法を示しています。これを実行して（サーバーのタイプをサーバーに合わせて変更します）、スレッドに必要なメモリー量を計算します。

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

データベースのメモリがすべてのデータベースに均等に分散されている場合、各データベースに12.8メガしかありません（15 * 1024）/1200=12.8。より多くのメモリが必要です。

パフォーマンスが低下する理由を調べる必要があります。ロック、ブロックなどを見ていますか？待機統計はどのようなものですか？

DBCCコマンドは、メモリを解放してOSに戻さないメモリバッファのみをクリアします。

SQL Serverが実際にメモリを消費していることを知っていますか？Perfmonセッションのセットアップを検討するか、再起動後にDMV情報の収集を開始して、SQL Serverが何を実行しているかを確認することをお勧めします。また、収集時間中にユーザーが通常よりも多くの作業（月末処理など）を行っている場合にも注意してください。同じサーバーでSSRS、SSIS、またはSSASを実行していますか？

システムに1200個のデータベースがありますが、DBの最大サイズはどれくらいですか？