spamd が AWS EC2 インスタンスで大量の CPU クレジットを使用しています

spamd が AWS EC2 インスタンスで大量の CPU クレジットを使用しています

AWS に EC2 マイクロインスタンスがあり、spamassassin を実行しています。最近、5 分間に 0.5 CPU クレジットを一貫して使用しています。(つまり、CPU は 5 分間に 50% で動作しています)。

spamd の実行頻度を減らすか、spamd が使用する CPU の総量を減らす方法はありますか?

ありがとう!

編集: この投稿では、fail2ban が CPU 使用率の原因であると誤って述べていました。fail2ban をオフにした後も、大量の CPU クレジットが使用されていたため、別の原因が見つかりました。

答え1

Spamd はスケジュールされるものではありません。プロセスが呼び出すたびに実行されます。

簡単な答えはなく、答えの多くは「設定によって異なります」ですが、(通常の電子メール サーバー/ユーザー プロファイルがあると仮定すると)グレー リストを導入することで、サーバーが処理する必要がある電子メールの量を大幅に削減できます。

(グレーリストは、受信スパムを削除する簡単な方法です。通常、スパムの約 80% を削除します。通常、ほとんどの電子メールはスパムであるため、かなりの違いがあります。グレーリストは、他のサーバーが接続して送信元アドレスと宛先アドレスを送信できるようにすることで機能します。これらのアドレスが認識されない場合は、リストに追加して接続を閉じます。正当なメール サーバーは電子メールの再送信を試みることになっていますが、多くのスパム システムではそうしません。欠点は、人々が最初に互いに通信するときに、最初の電子メールが届くまでに時間がかかることです)。

おそらくお勧めはしませんが、ブラックリストを使用して、スパムの可能性があるソースからのメールが spamassassin に到達する前にブロックすることもできます。これは、メールをチェックするために spamassassin を使用するよりもはるかに軽量ですが、RBL に多くの信頼 (おそらく信頼しすぎ) を与えます。

サーバーが大量のメールを送信していて、そのすべてが正当なものであると確信している場合は、送信メールのスパム フィルタリングをバイパスすることをお勧めします。ただし、サーバー経由でメールを送信している誰かが侵害された場合、ブラックリストに載せられる可能性が高くなります。クォータ (例: "cluebringer/policyd") を導入することで、これをある程度回避できる可能性があります。

最後に、CPU の負荷を軽減するために、spamassassin の一部を削除することもできます。ただし、これはおそらく良い考えではありません。

関連情報