スケジュールでサーバーを再起動すると、パフォーマンスが向上しますか？

スケジュールでサーバーを再起動することがパフォーマンスにとって良い考えかと思います。

2泊ごとに午前02:00にサーバーを再起動するとします。

ここにあるサーバーはWindows Server 2008 R2です。主に、SQL ServerとIIS 7.5（ほぼ15個のアプリが実行されています）がこのサーバーで実行されています。サーバーには4GBのメモリがあります。

SQL Serverエージェントが停止しているというあなたのコメントに基づいて、ボックス自体を再起動することに何の問題もないことに同意しますが、追加の根本原因分析をお勧めします。通常、サービスは単に停止するだけでなく、SQL Server Agentサービスは通常、私の経験ではそのように動作していません。

再起動は別として、イベントログを調べ、ログのパフォーマンス分析（PAL）で分析できる長期パフォーマンスカウンターログを実行して、問題を「見ている」かどうかを確認することをお勧めします。SQL Agentの停止に関連するイベントを他の要因と相関させるには、他に方法はありませんが、試みる必要があります。

パフォーマンスを向上させるためにコンピューターを再起動する場合は、おそらく最終的にメモリ管理の問題に直面していることを意味します。

キャッシングは良い

どちらかといえば、より理想的な環境でサーバーを再起動すると、パフォーマンス（そしてもちろん稼働時間）が損なわれます。コンピューティングのパフォーマンスの基本の1つは、キャッシュ（高速メモリで利用可能なデータを持つ）を活用することです。リブートするたびに、キャッシュが吹き飛ばされます。これは、SQLサーバーとIISの両方に当てはまります。理想的な環境ではないかもしれませんが、次のことは、スケジュールに従ってサーバーを再起動するよりも優れたオプションに導くのに役立ちます。

IISのメモリリーク？

さて、これはIIS 7.5であると述べました。気の毒ですが、IIS 7.5で実行される多くのWebアプリにはメモリリークがあり、IISのデフォルトでは、X分ごとにAPPを再起動し、APPプールがアイドル状態の場合はシャットダウンします。理想はメモリリークを修正することですが、それができない場合は、メモリ制限やタイマーを含むこれらの設定を調整することができます。perfmonを使用して、メモリを使用しているw3wpプロセスを特定できます。それは少し苦痛ですが、あなたはそれをアプリプールに戻すことができます%systemroot%\system32\inetsrv\APPCMD list wps。

SQLメモリ

キャッシュに戻ると、SQLは可能なメモリを使用します。SQLサーバーのプロパティでこれを制限できます。メモリを制限せず、ボックスでIISを実行している場合、これらはメモリを殺すパフォーマンスを求めて戦い始める可能性があります。この優れた記事は、これについて詳しく説明しています。MicrosoftSQL Memoryのシステム管理者ガイド。

残高

同じボックスにIISとSQLの両方があるため、メモリ使用量のバランスを取る必要があります。そうしないと、再び使用される可能性が高いメモリがディスクにスワップアウトされる可能性があります-これは恐ろしい場所です（スワップアクティビティにはperfmonカウンタが必要です）。IISリサイクル設定とSQLメモリ制限を使用することにより、このシステムを安定させることができます。これをバランスさせるには、4GB以上のメモリが必要になる場合があります。また、オプションの場合は、専用のマシンにSQLサーバーを配置することを強くお勧めします。これにより、パフォーマンスが大幅に向上し、物事が大幅に簡素化されます。

私は、特に根本的な問題を解決する手段としてではなく、スケジュールに従ってサーバーを再起動することを支持していません。パフォーマンスの問題を解決するためにこのサーバーを再起動する必要がある場合は、問題の原因を見つけて解決することをお勧めします。通常のスケジュールでサーバーを再起動すると、根本的な問題がわかりにくくなります。

重大なメモリリークが発生した場合は、その理由を確認してください。それ以外の場合は、毎月更新して再起動してください。

上記のメモリリークや更新などの理由で、スケジュールどおりにサーバーを再起動する場合は、クラスタソリューションを検討してみてはどうでしょうか。別のサーバーを並行して設置し、ロードバランサーに接続します（単純なサーバーでも可能です）。サービスの稼働時間を失うことなく、サーバーがまったく起動しないことを心配せずに、必要なだけ再起動できます。あなたは外に出ます。

それは恐ろしいアイデアではありませんが、それが単に「ブードゥー」だとしたら、おそらくあなたにはあまり役に立たないでしょう。

ただし、これがパフォーマンスの改善に関する調査の終わりにならないようにする2つの理由があります。

1つは、将来のスケーラビリティです。停止が負荷、一定数のクエリ、キャッシュにヒットする特定のクエリ、クエリのコンパイル、またはbtreeインデックス作成のバグ、または現在毎日繰り返されるその他の問題の結果である場合、負荷としてより頻繁に発生する可能性があります時間とともに増加します。つぼみに挟む。

もう1つの問題は、再起動中に依存サービスからの着信要求を停止する必要があると思われることです。運用リズムを作成しました。毎日のタスクを実行する必要があるたびに、再起動に結び付けられます。ある時点で、6時間かかる大規模なローリングリスタートが発生します（ここでは誇張していませんが、複数の会社で発生しているのを見てきました）。夜の。

私の推奨事項は、SQLプロセスを監視し、必要に応じて再起動することです。以前のポスターで述べたように、SQLには、人々が考えるメモリリークはありません（90年代半ばにMSSQLチームにいた人として私は言います）。あなたはしたいあなたのデータベースサーバーがほぼ100％のメモリとCPUを使用します。それ以下はリソースを浪費しています。

コードの記述が不十分で、メモリリークが発生している場合、割り当てられたメモリをプールに戻す唯一の方法は、再起動することです。メモリにバインドされたプロセスがある場合、プールをクリーンな状態に更新すると、パフォーマンスが確実に向上します。しかし、これは実際にはパフォーマンスの問題を処理するための悪い方法です。実際の原因を突き止めて修正する必要があります。

それ以外の場合は、パッチ/アプリケーション/データの復元を適用するためのメンテナンスウィンドウが必要になるまで実行します。これは、パフォーマンスエンジニアが問題のサーバーを調べて、これがなぜ/どのような問題を引き起こしているのかを正確に確認する良い機会かもしれません。

それ自体は完全な答えではありませんが、サーバーにRAMを追加する実行可能なオプションですか？4GBは、IIS / SQL Serverマシンの低域の少しです。実際に専用のサーバーユニットであるか、サービスに組み込まれているデスクトップであるかに応じて、かなり低コストで8GB以上を取得できる場合があります。確かに、サーバーの場合、標準のデスクトップRAMよりも少し高いかもしれませんが、強制的に再起動するまでに少し時間がかかります。

そう言って、SQL ServerがRAMの最大80％を使用するように制限できるかどうかを確認するか、ログを見て、何が問題なのか、および/またはサービスが停止している理由を正確に調べます。

Windowsサーバーを使用している場合に対処しているSQLの問題とは関係なく、「なんらかの理由」で再起動せずに定期的にサーバーを再起動するパッチ適用ルーチンを実行している場合。「BIG MULTINATIONAL」で働いていたとき、毎月パッチを適用することが義務付けられていたため、すべてのサーバーが少なくとも1回は毎月リブートされました。

3台のサーバーでこれを行っています。1台は私たち、2台は顧客です。さまざまな理由でセットアップしました-1つのサーバー2008R1にはインストールの保留中の更新が多数ありますが、それらをバッチインストールすることはできないため、毎日1つずつインストールします。別のサーバー2012R2-ブートのトラブルシューティングやパフォーマンスの問題など。他のハードから定期的な再起動をスケジュールすることは悪い習慣ではないと思います。特に自動起動に関係するハードウェアおよびソフトウェアのさまざまな問題を追跡するのに役立ちます。

毎晩Windowsサーバーを再起動するだけでなく、24時間ごとに再インストールする会社もあります。彼らにとっては、ソフトウェアとセキュリティの問題におけるメモリリークのために必要です。

一部の企業は24時間ごとに再起動しているようです-Linux管理者としては奇妙に思えますが。明確にするために：メモリの問題があるため、これを行うことはお勧めしません。問題を追跡して解決してください。

メモリ使用量が数か月間75％に固定されている場合、再起動する必要はおそらくありません-サーバーアプリケーションが利用可能なすべてのメモリを使用することは完全に正常です-データをキャッシュするRAM。