現在、SaaSシステムのサーバークラスタを管理しています。現在、MSSQL 2008 R2を実行しているSQLサーバーが6台あります。各サーバーは、16GBのRAMサーバーラックにプロビジョニングされます。各サーバーには、SQL Serverで許可されている最大50のインスタンスが読み込まれます。各インスタンスには、最大10のクライアントが同時に散発的にアクセスします。各データベースは、通常、約100MBから500MBのみです。サイズ。
現在、各インスタンスはメモリ制限を設定せずにインストールされていますが、最初のインスタンスはメモリを使いすぎる傾向があり、それ以降のインスタンスは(開始順に)わずか200MBで動作し、サーバーOSは1%の物理メモリが利用可能。これにより、過度のディスクスワッピングと遅延の問題が発生するようです。
この場合、メモリ割り当てを分割するための推奨される方法は何ですか?クライアントの数とデータベースのサイズから、1つのインスタンスに最低限必要なメモリの概算を決定する式はありますか?インスタンスごとに最大300MBを設定してそれで完了できますか?
私はようやく、非常に安定しているように見え、すべてのインスタンスにわたって完全に対称であるすべてのものを構成する方法を見つけました。それはいくつかの掘り下げを行うので、私が得たソリューションを共有する必要があると思いました。これはおそらくすべての人に適しているわけではありませんが、私にとっては最善の解決策のようです。
キーはこのAPIにあります: https://docs.Microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-setprocessworkingsetsizeex
これにより、プロセスごとに最小および最大のワーキングセットサイズにハードリミットを設定できます。これは、SQLサーバーにこのワーキングセットサイズ内で必要なだけのメモリを使用するように指示できるため、最もクリーンなようです。また、容量で実行してより多くのメモリを占有するのではなく、それ自体で適切に最適化されるようですいつも。各インスタンスはより全体的にスワップしますが、使用量はインスタンスごとに散発的であるため、問題なく動作するようで、問題が発生した場合は、サーバーラックのSSDからいくつかのスワップパーティションを各サーバーのスワップスペースとしてプロビジョニングできます。各インスタンスの起動時に、Powershellスクリプトを介して各インスタンスのワーキングセットサイズを300MBに設定しました。最小OSは常に1GBで動作し、誰もが十分満足しているようです。
各サーバーは、サーバーラック上にプロビジョニングされた16GBのRAMを備えたクアッドコア仮想マシンです。
SQL Serverで許可されている最大50のインスタンスを各サーバーに入力します。各インスタンスには、最大10のクライアントが同時に散発的にアクセスし、各データベースには通常、サイズは100MBから500MB程度です。
私見、あなたの合計RAMが低すぎます。私の答えを読んでください(関連リンク付き)SQL Serverの最大および最小メモリ構成 。特定のホスト上でSQLサーバーの複数のインスタンスを実行している場合、これらは変化します。
マルチインスタンスサーバーでのSQLサーバーの最大メモリの上限設定はバランスをとる行為であり、最大メモリはバッファプールにのみ適用できます。 SQLサーバーがより多くのメモリを必要とする場合、それを使用します 。
Lock Pages in Memory を使用することもできます(この場合、LPMを有効にする前に、さらに多くのメモリを選択します)。
出発点として、
インスタンスのベースライン 。これは、ワークロードに適している/許容できるものを評価するのに役立ちます。
OptimizeInstanceMemory
script from Aaron's blog を使用して、作業を開始します。ブログの投稿では、フェイルオーバーが発生したときに動的に最大メモリのバランスをとる方法について説明しています。
補足として、CPU、メモリ、ディスクの使用率を監視し、クライアントごとの使用量に基づいて、それらにも課金する必要があります。または、Azureに移動することもできます:-)
インスタンスごとに最大300MBを設定し、それで完了します。真剣に、あなたはこのようなものでそれを監視して、少し多かれ少なかれ与える候補であるかもしれないものを決定することができます。
SELECT DB_NAME(database_id) AS [Database Name],
COUNT(*) * 8/1024.0 AS [Cached Size (MB)]
FROM sys.dm_os_buffer_descriptors
WHERE database_id > 4 -- system databases
AND database_id <> 32767 -- ResourceDB
GROUP BY DB_NAME(database_id)
ORDER BY [Cached Size (MB)] DESC OPTION (RECOMPILE);
ここから: データベースごとのメモリ使用率-SQL Server
ここに良い記事: http://strictlysql.blogspot.com/2013/05/how-to-size-sql-server-memory-why-is-it.html
OSへのメモリの割り当て(記事から):
1 GB of memory reserved to Operating System
1 GB each for every 4 GB in 4 to 16 GB
1 GB each for every 8 GB in more than 16 GB.
残り(12 GBなど)を50のDBに均等に分割します(約250 MB)。
また、検討すべき1つの構成は、「アドホックワークロードの最適化」をオンにすることです。これにより、少なくとも2回実行されるまで、クエリの完全なクエリプランをキャッシュしないようにSQLサーバーに指示されます。これにより、「アドホック」または使い捨てクエリがこの限られたメモリを占有するのを防ぎます。
また、トランザクションログを「シンプル」リカバリモードに設定することで、メモリへの影響を最小限に抑えることができます。これができるのは、障害が発生した場合に、最後のバックアップから復元しても問題ない場合のみです。その他の制限については、こちら https://msdn.Microsoft.com/en-us/library/ms189275.aspx をご覧ください。
特に他のすべての点で同等である個人のクライアントである場合は、それを変更する理由がわかるまでは公平だと思います。