私たちは新しいLinux / Exim / Spamassassinメールサーバーを金曜日に展開しました(管理者がいない週末の長い前日の展開を常にお勧めします)。負荷は15分間の平均で1.3前後で推移しています。
マシンは応答性が高く、メールは妥当な時間内に配信されます。これは許容できると思いますか?
特定の量の負荷を許容できるか、許容できないと見なすのですか?どの指標が使用されていますか?
私たちは新しいLinux / Exim / Spamassassinメールサーバーを金曜日に展開しました(管理者がいない週末の長い前日の展開を常にお勧めします)。負荷は15分間の平均で1.3前後で推移しています。
マシンは応答性が高く、メールは妥当な時間内に配信されます。これは許容できると思いますか?
特定の量の負荷を許容できるか、許容できないと見なすのですか?どの指標が使用されていますか?
回答:
基本的な経験則:システムが応答性があり、タイムリーに機能している場合は問題ありません。
2未満の負荷はそれほど心配する必要はありません。システムが4または5にヒットしても問題なく動作しましたが、ネットワークまたはドライブにキューイングの問題がたくさんあることを示しています(システムが非常に応答性が高いにもかかわらず、I / Oの問題が原因で高負荷が発生する可能性があります)。
メールキューの長さを定期的に確認し、配信できない問題やそのような問題がないかログを確認してください。配信キューが比較的低いままであれば問題ありません。
ディスクの平均とネットワークI / O情報を取得することで多くの問題を回避できますが、配信の問題が表示されない場合(メッセージは15分前に送信しましたが、まだ到着していません!)、コンソールからシステムで作業できます(またはssh)多くの待ち時間がなければ、大丈夫です。
負荷平均は、待機せずに必要なときにすべてのタスクを実行できるようにするためにカーネルが必要とするプロセッサーの数を示す値です。
あなたのケースでは、あなたが2つ以上のCPU /コアを持っている場合。問題はない。1コアのCPUが1つしかない場合は、アプリが実行したい時間とカーネルが実行する時間との間に「時間」が多すぎることを意味します。負荷>「CPU /コアの数」は、非常に長い時間、高すぎる値に達するまで、メールシステムでは問題になりません。
もちろん、それらはルールや価値を与えるものではありません。短時間でメールを受信している間は問題ありません。しかし、「長い」期間(〜1時間)の間、負荷が2 * cpu /コアの数より頻繁に多い場合は、サーバーを注意深く調べる必要があるでしょう。
メールサーバーの場合も、これは大きな問題ではありませんが、サーバーが少し過負荷になっていることを意味し始めます。
いつもチューニング関連の質問と同じように、はい/いいえの答えはありません、それはすべて依存します:-)
そうは言っても、特にマルチコアCPU構成の場合、1.3の負荷は高く聞こえません。ロード数がコアの数と同じである場合、すべてのコアには常に実行可能なプロセスがあります。
最終的に、あなたが言うように、メッセージがタイムリーに配信されている場合、パフォーマンスは良好です:-)
top
ほぼリアルタイムで基本的な指標を提供します。
負荷の平均がCPUの数よりも少ないということは、CPUが何もすることなく座っていることを意味します。等しいとは、現時点ですべてが機能していることを意味します。大きいということは、実行中のプロセスはありますが、並んで待機しているということです。
VoIPサーバーやmemcacheなどの非常に時間に敏感なものの場合は、負荷平均をコアの数よりもかなり少なくしたいとします。時々のバックアップ(電子メールなど)に対応できる非同期のものについては、4倍の数のコアを簡単に実行できます。
覚えておくべき最大の注意点は、ディスクまたはネットワークI / Oを待機しているが、それ以外の場合は実行可能なプロセスが、依然として負荷平均に表示されることです。したがって、apacheサーバーが56kユーザーにjpgをスプーンフィードしている場合は、ギガビットLANを介してphp / whatever-script応答をプロキシ/ロードバランサーに送り返す場合よりも、はるかに高い負荷平均を実行できます。あなたの場合、添付ファイルの転送に永遠にかかる遅いメールサーバーへのSMTP接続は、実行キューに1プロセスを表示しますが、20回中断されて問題なくGmailに迅速なワンライナーメールを送信する可能性があります。
プッシュが発生し、負荷平均はDOWに似ています。実際には「経済」を測定するものではありません。人々はそれを非常に緩やかに相関するメトリックとして使用するだけで、簡単に話すことができます。配信キューの深さや1秒あたりのメッセージなど、実際に関心のある指標の監視に焦点を当てます。
はい、それはかなり受け入れられるものであり、一般にメールフィルタで期待されるものです。
私たちのセットアップは少し異なります。SpamAssassinには別のサーバーがあり、POPサーバーはClamAVを実行してウイルスをスキャンしています。POPサーバーは通常2のサーバー負荷で実行されていますが、ときどき最大10以上に急上昇します。一方、SpamAssassinサーバーは、Openprotect.comフィルターをインストールするまで約2で実行されていましたが、CPU使用率が2倍になり、約5で実行され、15を超えるスパイクが発生しました。これは、メールの遅延によりメールキューが増大します(受信SMTPにはqmailを使用します)。また、CPU使用率/メモリを節約する余地はまだあります。
偶然にも、サーバーの監視にはMuninを強くお勧めします。これは、履歴データを視覚的に示し、どのリソースを節約する必要があるかを示すのに役立ちます。Top(1)を使用したリアルタイムの監視はあまり役に立ちません。:)
ああ、ちなみに、長い週末の前に金曜日に展開することは、週末全体を作業するのに最適な方法です。特にメールサーバーなどの重要なシステムの場合。
collectd
ここに述べたように、:serverfault.com/questions/67234/...