パフォーマンスを向上させるために、サーバーを定期的に再起動することをお勧めしますか？
パフォーマンスを向上させるために、サーバーをスケジュールに基づいて再起動するのは良い方法でしょうか。
サーバーを2泊午前2時に再起動するとします。
ここのサーバーはWindows Server 2008 R2。主に、SQL ServerとIIS 7.5（約15のアプリが実行中）がこのサーバーで実行されています。サーバーには4GBのメモリがあります。
SQL Serverエージェントが停止しているというコメントに基づいて、ボックス自体を再起動しても問題はないことに同意しますが、根本的な原因の分析を追加で行うことをお勧めします。サービスは通常、単に停止するだけではなく、SQL Serverエージェントサービスは、通常、私の経験ではそのように機能していません。
再起動は別として、イベントログを調べ、長期的なパフォーマンスカウンターログを実行して、 Performance Analysis of Logs （PAL）で実行して、それが存在するかどうかを確認するとうまくいくと思います何かが間違っているように見えます。他に何もない場合は、SQLエージェントの停止に関連するイベントを他の要因と関連付けるようにしてください。
パフォーマンスを改善するためにコンピューターを再起動することを検討している場合、おそらく最終的にメモリ管理の問題が発生していることを意味します。
キャッシングは良い
どちらかと言えば、サーバーを再起動すると、より多くの理想的な環境でパフォーマンス（およびもちろん稼働時間）が低下します。コンピューティングのパフォーマンスの基本の1つは、caching（高速メモリでデータを利用できるようにする）を利用することです。再起動するたびに、キャッシュが吹き飛ばされます。これは、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）を実行している場合、これらはメモリキルパフォーマンスをめぐって戦い始める可能性があります。この優れた記事は、これについて詳しく説明しています： Microsoft SQLメモリのシステム管理者用ガイド 。
残高
同じボックスにIISとSQLの両方があるため、それらのメモリ使用量のバランスをとる必要があります。バランスが取れていない場合、再度使用される可能性のあるメモリがスワップアウトされます。ディスク-これはひどい場所です（スワップアクティビティにはperfmonカウンターが必要です）IISリサイクル設定とSQLメモリの制限を使用すると、このシステムを作成できるはずです。これをバランスさせるには、4GBよりも多くのメモリが必要になる場合があります。また、オプションの場合は、SQLサーバーを専用マシンに配置することを強くお勧めします。これにより、パフォーマンスが大幅に向上し、物事が大幅に簡素化されます。
私は、サーバーを定期的に再起動することの支持者ではありません。特に、根本的な問題を解決する手段としてではありません。パフォーマンスの問題を解決するためにこのサーバーを再起動する必要がある場合は、問題の原因を見つけて解決することをお勧めします。定期的なスケジュールでのサーバーの再起動は、根本的な問題を難読化するだけです。
重大なメモリリークがある場合は、その理由を確認してください。それ以外の場合は、毎月更新して再起動してください。
（上記のメモリリークや更新、その他の理由により）サーバーを定期的に再起動したい場合は、クラスタソリューションを調べてみませんか？別のサーバーを並列に配置し、それらをロードバランサーに接続します（単純なサーバーでも可能です）。サービスの稼働時間を失わず、サーバーがまったく起動しないことを心配することなく、必要なだけサーバーを再起動できます。あなたは外出するでしょう。
これは恐ろしいの考えではありませんが、単に「ブードゥー」だとしたら、おそらくあまり役に立たないでしょう。
ただし、これでパフォーマンスの改善に関する調査が終了しないようにする2つの理由があります。
1つは、将来のスケーラビリティです。停止が負荷、特定の数のクエリ、キャッシュにヒットする特定のクエリ、クエリのコンパイル、またはbtreeインデックス作成のバグ、または現在毎日繰り返し発生しているその他の問題の結果である場合、それらはおそらく負荷としてより頻繁に発生します時間とともに増加します。つぼみでそれをニップします。
もう1つの問題は、再起動中に依存サービスからの着信要求を停止する必要があると思われることです。運用上のケイデンスを作成しました。いくつかの毎日のタスクを実行する必要があるたびに、それは再起動に結びついてしまいます。ある時点で、これらの大規模なローリングリスタートが6時間かかります（ここでは大げさではありませんが、複数の会社で発生することを確認しました）。夜の。
私の推奨は、SQLプロセスを監視し、必要に応じて再起動することです。以前のポスターで述べたように、SQLにはメモリリークはありません（90年代半ばにMSSQLチームに所属していた人物と言います）。あなたはwantほぼ100％のメモリとCPUを使用するデータベースサーバー。それより少ないものはリソースを浪費しています。
不十分なコードとメモリリークがある場合、再起動が割り当てられたメモリをプールに戻す唯一の方法である可能性があります。メモリにバインドされたプロセスがある場合は、プールをクリーンな状態に更新することで、しばらくの間は確かにパフォーマンスを向上させることができます。しかし、これはパフォーマンスの問題を処理するには本当に悪い方法です。実際の原因を突き止めて修正する必要があります。
それ以外の場合は、パッチ、アプリケーション、データの復元を適用するためのメンテナンスウィンドウが必要になるまで実行します。これは、パフォーマンスエンジニアが問題のサーバーを調べて、なぜなぜ/どのような問題がこれを強制するのかを正確に調べることを提案する良い機会かもしれません。
完全な答えではありませんがそれ自体ですが、サーバーにさらにいくつかのRAM=を追加することは実行可能なオプションですか？4GBはIISの下位側に少しあります/ SQL Serverマシン。実際に専用のサーバーユニットであるか、サービスに組み込まれているデスクトップであるかに応じて、かなり低いコストで8 GB以上を入手できる可能性があります。サーバーである場合は、それよりも少し高くなる可能性があります。標準デスクトップRAMですが、強制的に再起動するまでに少し時間がかかります。
つまり、SQL ServerがRAMの最大80％を使用するように制限できるかどうかを確認するか、ログを調べて問題の原因やサービスが停止している理由を正確に特定します。
3つのサーバーでこれを行うと、1つは私たちで、2つは顧客です。さまざまな理由で設定しました-1台のサーバー2008R1にインストール待ちの更新が多数ありますが、それらを一括インストールすることはできないため、毎日1つずつインストールしています。別のサーバー2012R2-ブートのトラブルシューティングやいくつかのパフォーマンスの問題など。定期的な再起動をスケジュールするのは悪い習慣ではないと思います。他のハードからハードウェアやソフトウェアのさまざまな問題、特に自動起動に関連する問題を追跡するのに役立ちます。 。
Windowsサーバーがあり、何らかのパッチルーチンを実行している場合に対処するSQLの問題とは関係なく、「理由」で再起動する必要なくサーバーを定期的に再起動します。私が "BIG MULTINATIONAL"で働いていたとき、私たちは毎月パッチを適用するように義務付けられていたため、すべてのサーバーは少なくとも月に一度は再起動されました。