SQL Serverを使っていると、メモリやデータベースファイルの容量設定を確認することがあります。
私もSQL Serverを扱う中で、max server memory の設定値を見て、「このままで大丈夫なのか」と気になったことがありました。
SQL Serverだけがサーバーのメモリを使うわけではありません。
OS自体もメモリを使いますし、同じサーバー上で他のシステムやプロセスが動いている場合は、その分も考える必要があります。
私が担当していた環境では、OSや他のシステムが使う分を残しながら、max server memory の上限値を決めていました。
この記事では、SQL Serverの max server memory とDBファイル容量について、私が実務でどのように考えていたのかを紹介します。
max server memoryはSQL Serverのメモリ使用を考えるための設定
SQL Serverには、max server memory (MB) という設定があります。
Microsoftの公式ドキュメントでは、max server memory (MB) の既定値は2,147,483,647MBとされています。
私が設定値を確認したときも、非常に大きな値だったため、このままではOSや他の処理とメモリを取り合う可能性があるのではないかと考えました。
Microsoftは、SQL ServerによってOSや他のアプリケーションに有害なメモリプレッシャーがかからないよう、max server memory に上限を設定することを推奨しています。
一方で、max server memory はSQL Serverが使うすべてのメモリを完全に制限する設定ではありません。
Microsoftの説明では、この設定の対象外となるメモリ割り当てもあります。
そのため、上限値を決めるときには、SQL Serverだけを見るのではなく、OSや他のアプリケーションが使うメモリも含めて考える必要があります。
現在のMicrosoft公式ドキュメントでは、他のプロセスで使用されていない利用可能なシステムメモリの75％という簡略的な推奨値も示されています。
さらに詳しく決める場合は、OSが必要とするメモリ、max server memory の対象外となるSQL Serverのメモリ、他のSQL Serverインスタンスやアプリケーションが使うメモリなどを考慮するよう説明されています。
Microsoft Learn「サーバー メモリ構成オプション」
自分の環境では25～50％程度を目安にしていた
私が担当していた環境では、max server memory を考えるとき、サーバー全体のメモリの25～50％程度を目安にすることがありました。
理由は、SQL Server以外にもメモリを使うシステムがあったためです。
ただし、25～50％はMicrosoftの推奨値ではなく、当時担当していた環境に合わせて変えていた運用上の目安です。
固定していたわけではなく、OSや構成によって上限値を調整していました。
設定値を確認するようになった背景には、DBが原因かもしれないと感じるほどメモリが使われているように見えたこともありました。
ただし、その事象についてSQL Serverが原因だったと断定できたわけではありません。
メモリ設定を確認したことでDBファイル容量も気になった
max server memory の設定を確認しているうちに、「DBファイルの容量はどこまで大きくなる設定なのか」と気になり、DBファイルの容量設定も確認するようになりました。
私が担当していた環境では、当初はDBファイルの容量に制限を設けていました。
その後、運用では自動拡張を使うようになりました。
DBファイルは途中から自動拡張を使っていた
DBファイルを自動拡張にした場合でも、ディスク容量そのものに限界があることは変わりません。
Microsoftの公式情報でも、autogrowを利用している場合には、利用可能なディスク容量を別途確認する必要があるとされています。
また、Microsoftは、管理された本番システムではautogrowを予期しない容量増加への備えとして考え、日常的なデータファイルやログファイルの容量管理をautogrowだけに任せないよう案内しています。
ファイルが使用可能なディスク領域を使い切らないよう、各ファイルに MAXSIZE を設定することもベストプラクティスとして挙げられています。
Microsoft Learn「自動拡張と自動圧縮に関する考慮事項」
一方、私が担当していた環境では、途中からDBファイルを自動拡張にしていました。
その際、ディスク容量については別の仕組みでも監視していました。
ディスク容量はVMやAWS側のアラームで監視していた
私が担当していた環境では、ディスク使用率が80％や90％を超えた場合に、VMやAWS側の上位監視からアラーム通知が飛ぶようにしていました。
そのため、DBファイルが自動拡張する設定でも、ディスク容量が限界に近づけば別の監視から気づける状態になっていました。
この仕組みにしてからは、ディスク空き容量を人が常に確認する必要は減りました。
私の感覚では、DBファイルを自動拡張にしたことで容量を気にしなくなったのではなく、容量確認を手作業から監視・アラームへ移したという方が近いです。
メモリとDB容量は別でも、サーバー全体を見るようにしていた
max server memory とDBファイル容量は別の設定です。
max server memory はSQL Serverのメモリ使用を考えるための設定で、DBファイル容量はデータやログを保存するストレージ側の話です。
ただ、実際に運用していると、どちらか一つだけを見ていればよいとは感じませんでした。
私の場合は、max server memory の設定を確認したことをきっかけに、DBファイル容量にも目を向けるようになりました。
確認していた対象は違いますが、
- OSや他のシステムが使うメモリ
- SQL Serverの max server memory 設定
- DBファイルの増加
- ディスクの空き容量
- 監視やアラーム
を含めて、サーバー全体の状態を見るようにしていました。
まとめ：SQL Serverだけでなく周囲のリソースも見ていた
私がSQL Serverの max server memory を確認するときは、SQL Serverだけにどれだけメモリを割り当てられるかを見るのではなく、OSや他のシステムが使う分も考えていました。
また、メモリ設定を確認したことをきっかけにDBファイル容量も確認し、途中からは自動拡張を使っていました。
その際も容量監視をやめたわけではなく、ディスク使用率が80％や90％に達した場合にVMやAWS側からアラームを出すことで、別の仕組みから監視していました。
私の経験では、SQL Serverの設定値だけを見るのではなく、OS、他のシステム、DBファイル、ディスク、監視まで含めて見ることが、実際の運用では重要でした。
