So sollte eine gute Reparatur aussehen
Wenn ein amavisdProzess die CPU zu 100 % oder nahezu 100 % auslastet, reicht es nicht aus, ihn einfach zu beenden. Eine sinnvolle Lösung sollte den normalen E-Mail-Verkehr wiederherstellen, die Verarbeitungsverzögerung reduzieren, den Spam- und Virenschutz aufrechterhalten und ein weiteres Anwachsen der Postfix-Warteschlange verhindern.
In Zimbra fungiert Amavisd-New als Schnittstelle zwischen dem Mail Transfer Agent (MTA) und den Inhaltsscannern. Laut dem aktuellen Daffodil-Administrationshandbuch von Zimbra ist Amavisd-New die Schnittstelle zwischen dem Zimbra MTA, ClamAV und SpamAssassin. Daher kann eine CPU-Spitze durch Amavis selbst, durch SpamAssassin-Regeln oder Nachrichteninhalte, durch Virenscans oder durch einen Bearbeitungsstau, der alle verfügbaren Worker auslastet, verursacht werden. Weitere Informationen finden Sie im Zimbra Daffodil-Administratorhandbuch .
Ein erfolgreiches Ergebnis zeigt sich durch vier Anzeichen: Die CPU-Auslastung von Amavis sinkt auf ein nachhaltiges Niveau, die Anzahl der verzögerten und aktiven Warteschlangen steigt nicht mehr an, neue Nachrichten werden ohne ungewöhnliche Verzögerung verarbeitet und die Anti-Spam-/Antiviren-Dienste funktionieren einwandfrei. Sinkt die CPU-Auslastung nur aufgrund deaktivierter Filter, ist das zugrundeliegende Problem nicht behoben.
Schritt 1: Bestätigen Sie, dass Amavis tatsächlich der CPU-Verbraucher ist.
Beginnen Sie auf Betriebssystemebene. Gehen Sie nicht automatisch davon aus, dass Amavis die Ursache ist, nur weil die E-Mail-Zustellung langsam ist. Überprüfen Sie die am stärksten ausgelasteten Prozesse und stellen Sie fest, ob ein oder mehrere amavisddieser Prozesse dauerhaft einen gesamten CPU-Kern belegen.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Bildunterschrift: Eine Terminalansicht, in der amavisd den größten Anteil der CPU-Leistung beansprucht. Dies ist die erste Bedingung, die vor einer Änderung der Zimbra-Einstellungen überprüft werden sollte.
Ein kurzer Spitzenwert kann beim Scannen einer großen Nachricht oder eines komprimierten Anhangs normal sein. Gehen Sie von einem anhaltenden Problem aus, wenn die gleichen Symptome trotz Verzögerungen beim E-Mail-Versand oder zunehmender Warteschlangenlänge fortbestehen. Überprüfen Sie außerdem die Systemlast, den freien Speicher, die Auslagerungsaktivität und die E/A-Wartezeiten. Eine hohe CPU-Auslastung in Verbindung mit starker Auslagerung oder Speicherkonflikten erfordert möglicherweise eine umfassendere Untersuchung auf Host-Ebene anstatt einer reinen Amavis-Anpassung.
Schritt 2: Überprüfen Sie den Zustand der Zimbra-Dienste, bevor Sie irgendetwas neu starten.
Wechseln Sie zum Zimbra-Konto und überprüfen Sie den Dienststatus. Die Zimbra-Dokumentation verwendet dies zmcontrol statusals Standardprüfung für aktivierte Dienste.
su - zimbra
zmcontrol status
zmamavisdctl status
Bildunterschrift: Zimbra-Dienststatus, der anzeigt, dass die Komponenten Amavis, Anti-Spam, Antivirus und MTA vor Beginn der Fehlerbehebung ausgeführt werden.
Dieser Schritt ist wichtig, da „100 % CPU-Auslastung“ und „Dienstausfall“ unterschiedliche Fehlermodi darstellen. Falls Amavis nicht läuft, untersuchen Sie stattdessen Startfehler. Falls Amavis läuft, aber die CPU-Auslastung hoch ist, fahren Sie mit der Analyse der Warteschlange und der Protokolle fort.
Schritt 3: Messen Sie die E-Mail-Warteschlange, nicht nur die CPU-Auslastung.
Die Warteschlangenlänge gibt Aufschluss darüber, ob eine hohe CPU-Auslastung die Zustellung beeinträchtigt. Zimbra bietet Dokumentationen zur Fehlerbehebung in der Warteschlange, zmqstatum die Anzahl der Warteschlangenmitglieder zu ermitteln, und Postfix verwendet Warteschlangenbefehle für Details zu den Nachrichten. Führen Sie die Prüfungen im Abstand von einigen Minuten wiederholt durch.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Bildunterschrift: Warteschlangenstatistiken und verzögerte Nachrichten bieten ein besseres Maß für die Auswirkungen auf den E-Mail-Verkehr als die CPU-Auslastung allein.
Achten Sie auf die Richtung, nicht auf eine einzelne Zahl. Eine Warteschlange, die bei jeder Messung ansteigt, bedeutet, dass der Durchsatz unter der Ankunftsrate liegt. Eine Warteschlange, die nach einer Änderung stetig sinkt, ist eines der stärksten Anzeichen dafür, dass die Änderung tatsächlich geholfen hat.
Bei einer Multi-MTA-Bereitstellung sollten Sie den betroffenen MTA-Knoten gesondert prüfen. Gehen Sie nicht davon aus, dass die Warteschlange auf einem anderen Knoten denselben Engpass widerspiegelt.
Schritt 4: Verwenden Sie das Zimbra-Protokoll, um die langsame Phase zu identifizieren.
Die Fehlermeldungen von Amavis und SpamAssassin werden in eine bestimmte Datei geschrieben /var/log/zimbra.log. Suchen Sie nach dem Zeitpunkt der CPU-Auslastungsspitze und korrelieren Sie die Meldungs-IDs, Prozess-IDs und Scan-Dauern.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Bildunterschrift: Anhand der Protokollzeilen von Amavis und SpamAssassin lässt sich erkennen, ob einzelne Nachrichten oder Scanvorgänge ungewöhnlich lange dauern.
Hilfreiche Muster sind wiederholte, lange SpamAssassin-Scans, wiederholte Versuche für dieselben Warteschlangen-IDs, ClamAV-Kommunikationsfehler, Dekomprimierungsfehler oder eine kleine Anzahl von Nachrichten, die wiederholt Ressourcen verbrauchen. Die Dokumentation zur Fehlerbehebung von Zimbra empfiehlt insbesondere die Verwendung von Amavis und SpamAssassin im Debug-Log, wenn Scanverzögerungen den E-Mail-Verkehr beeinträchtigen. Siehe die Dokumentation zur Fehlerbehebung bei Zimbra .
Schritt 5: Erhöhen Sie vorübergehend die Amavis-Protokollierung, falls die normale Protokollierung keine eindeutigen Ergebnisse liefert.
Zimbra bietet separate Protokollierungseinstellungen für Amavis und SpamAssassin. Der dokumentierte Amavis-Bereich reicht von 0 bis 5, während SpamAssassin die Werte zimbraAmavisSALogLevel0 oder 1 verwendet. Beginnen Sie mit Amavis-Stufe 2 anstatt der maximalen Ausführlichkeit, es sei denn, Sie benötigen eine detailliertere Fehlersuche.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Bildunterschrift: Temporäre Änderungen an der Protokollierung erleichtern die Korrelation von Scan-Zeitpunkt und SpamAssassin-Verhalten mit dem CPU-Spitzenwert.
Reproduzieren oder beobachten Sie das Problem nur so lange, wie es für die Erfassung nützlicher Daten erforderlich ist. Höhere Protokollierungsstufen erhöhen die Anzahl der Schreibvorgänge auf der Festplatte und können die Serverauslastung erhöhen. Stellen Sie nach der Untersuchung Ihre vorherigen Werte wieder her. Zimbra dokumentiert die standardmäßige Protokollierungsstufe von SpamAssassin mit 0 und die von Amavis mit einem normalerweise geringen Protokollierungsvolumen.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1
Schritt 6: Falls SpamAssassin die langsame Phase ist, überprüfen und aktualisieren Sie dessen Regeln.
Weisen die Protokolle durchgehend auf SpamAssassin hin, prüfen Sie, ob das Problem nach einer Regeländerung, der Bereitstellung benutzerdefinierter Regeln oder einem fehlgeschlagenen Regelupdate aufgetreten ist. Schlecht konzipierte reguläre Ausdrücke und problematische Regeln können bei bestimmten Nachrichtentexten zu hohen Spam-Raten führen.
Die offiziellen Amavis-Fehlerbehebungsunterlagen von Zimbra dokumentieren den mitgelieferten SpamAssassin-Update-Befehl für ZCS 8.8 und höher wie folgt:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Bildunterschrift: Die Aktualisierung der mitgelieferten SpamAssassin-Regeln ist angebracht, wenn Protokolle oder Startfehler auf veraltete oder beschädigte Regeldaten hinweisen.
Dies ist keine sa-updateuniverselle Lösung für die CPU-Auslastung. Wenn die Spitzenlast unmittelbar nach dem Hinzufügen einer benutzerdefinierten Regel auftrat, testen Sie diese Regel zuerst. Zimbra speichert moderne benutzerdefinierte SpamAssassin-Regeln unter `/etc/spamAssassin/` /opt/zimbra/data/spamassassin/localrules/. Entfernen oder deaktivieren Sie nur die verdächtige Anpassung in einem kontrollierten Wartungsfenster und vergleichen Sie anschließend die Scanzeit und das Verhalten der Warteschlange.
Das offizielle Zimbra-Wiki weist außerdem auf die automatischen Regelaktualisierungs- und Kompilierungseinstellungen für neuere ZCS-Versionen hin. Lesen Sie die Zimbra-Anti-Spam-Strategien, bevor Sie automatisierte Funktionen auf einem bestehenden Server aktivieren.
Schritt 7: Starten Sie Amavis erst neu, wenn Sie wissen, welche Änderungen Sie vorgenommen haben.
Ein Neustart kann blockierte Worker beheben und aktualisierte Regeln laden, sollte aber nach der Diagnose erfolgen und diese nicht ersetzen. Starten Sie zunächst nur Amavis neu, es sei denn, es gibt Hinweise auf ein Problem im gesamten MTA-Stack.
su - zimbra
zmamavisdctl restart
Bildunterschrift: Durch einen Neustart von Amavis wird der Dienst nach einer gezielten Regel- oder Konfigurationsänderung neu geladen, ohne dass unnötigerweise alle Zimbra-Dienste neu gestartet werden müssen.
Wenn die CPU-Auslastung sofort wieder 100 % erreicht, ist das ein hilfreicher Hinweis: Die Ursache besteht weiterhin. Überprüfen Sie die Protokolle erneut, um festzustellen, ob dieselbe Meldung, derselbe Scanner oder dieselbe Regel wieder auftritt. Durch wiederholtes Neustarten des Dienstes lassen sich die Symptome vorübergehend lindern, während die Warteschlange weiter anwächst.
Schritt 8: Überprüfen Sie die Wiederherstellung mit drei unabhängigen Prüfungen.
Betrachten Sie den Vorfall nicht als gelöst, nur weil die CPU-Auslastung einmalig gesunken ist. Überprüfen Sie gemeinsam die Prozesslast, die Warteschlangenrichtung und den Dienststatus.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Bildunterschrift: Die Wiederherstellung ist umso effektiver, je besser sich gleichzeitig die CPU-Auslastung, die Warteschlangenlänge und der Zimbra-Dienststatus verbessern.
Senden Sie anschließend eine Testnachricht über den betroffenen MTA und prüfen Sie, ob diese innerhalb Ihrer üblichen Latenzzeit zugestellt wird. Überprüfen Sie bei Nachrichten, die die Filterung passieren sollten, die Header auf die erwarteten Spam- und Virenscan-Felder von Zimbra/Amavis. Zimbra protokolliert Header wie beispielsweise [Beispiel-Header-Informationen einfügen], X-Virus-Scannedwenn X-Spam-Statusdiese Prüfungen aktiv sind.
Wie man entscheidet, was als Nächstes zu tun ist
| Was Sie beobachten | Beste nächste Maßnahme | Warum |
| Eine einzelne Nachricht verursacht wiederholt lange Scans. | Diese Nachricht sollte sicher unter Quarantäne gestellt oder geprüft und ihre Warteschlangen-ID mit den Protokollen abgeglichen werden. | Der Engpass könnte eher inhaltsbezogen als kapazitätsbezogen sein. |
| SpamAssassin-Timing ist entscheidend | Überprüfen Sie benutzerdefinierte Regeln, Regelaktualisierungen und Debug-Ausgaben. | Regelsätze mit vielen regulären Ausdrücken oder beschädigte Regelsätze können die Wertung teuer machen |
| ClamAV-Fehler oder Timeouts dominieren | Überprüfen Sie den Status Ihrer Antivirensoftware und aktualisieren Sie ihn. | Amavis wartet möglicherweise einfach auf den Scanner, den es anruft. |
| Die CPU-Auslastung ist hoch, aber die Warteschlangen bleiben nahezu leer. | Bevor man einschneidende Veränderungen vornimmt, sollte man länger beobachten. | Eine hohe Auslastung kann akzeptabel sein, solange Durchsatz und Latenz im grünen Bereich bleiben. |
| Die Warteschlangen wachsen auch nach gezielten Fehlerbehebungen. | Eskalation zur Kapazitäts-, Nachrichtenmuster- oder Supportebenenanalyse | Der Server könnte unterdimensioniert sein, einem Angriff ausgesetzt sein oder auf einen softwarespezifischen Fehler stoßen. |
Änderungen, die als erste Reaktion vermieden werden sollten
Deaktivieren Sie Antispam- oder Virenscans nicht dauerhaft, nur um die CPU-Auslastung zu reduzieren. Zimbra unterstützt zwar Umgehungsrichtlinien für bestimmten vertrauenswürdigen/ursprungsbezogenen Datenverkehr, dies ändert jedoch das Sicherheitsmodell und sollte eine bewusste Entscheidung in den E-Mail-Richtlinien sein, keine allgemeine Leistungsoptimierung. Die Dokumentation von Zimbra zur Umgehung von SpamAssassin-Datenverkehr stellt klar, dass diese Umgehung an vertrauenswürdige interne Netzwerke gebunden ist.
Erhöhen Sie die Anzahl der Amavis-Worker nicht unüberlegt. Mehr Worker können zwar die Parallelität erhöhen, aber auch den Speicherdruck steigern und die CPU-Auslastung verschärfen. Der optimale Wert hängt von der Nachrichtenzusammensetzung, der Größe der Anhänge, dem Scannerverhalten, den verfügbaren Kernen, dem Arbeitsspeicher und der E/A ab. Testen Sie Änderungen anhand des Durchsatzes und der Latenz der Warteschlange, anstatt anzunehmen, dass ein größerer Worker-Pool automatisch schneller ist.
Grenzen dieses Fehlerbehebungspfads
Dieses Verfahren ist für den häufigen Fall gedacht, dass Amavis zwar läuft, aber dauerhaft die CPU-Auslastung erhöht. Es ersetzt nicht die versionsspezifischen Support-Richtlinien von Zimbra für bestätigte Produktfehler, kompromittierte Server, Denial-of-Service-Angriffe mit fehlerhaften Nachrichten oder Architekturen mit mehreren Knoten und externen Scannern.
Die technischen Unterlagen der Zimbra-Community dokumentieren Fälle, in denen speziell präparierte Nachrichten oder das Verhalten von SpamAssassin die CPU-Auslastung von Amavis-Workern über längere Zeiträume stark erhöhen konnten. Da das genaue Ausmaß der Auslastung von den installierten Versionen von Zimbra und SpamAssassin abhängt, sollten Sie nicht einfach blindlings ein veraltetes Paket aktualisieren. Notieren Sie sich zunächst Ihre Zimbra-Version zmcontrol -v, vergleichen Sie sie mit Ihrer unterstützten Version und dem Patch-Level und befolgen Sie die aktuellen Empfehlungen des Herstellers für Aktualisierungen.
Checkliste zur abschließenden Überprüfung
- Die Amavis-CPU ist unter normalem Datenverkehr nicht mehr permanent ausgelastet.
- Deferred und Active Queues bleiben über wiederholte Messungen hinweg stabil oder schrumpfen.
- Neue Testnachrichten werden innerhalb einer akzeptablen Zeit über die MTA verarbeitet.
- Die Dienste von Amavis, Anti-Spam, Antivirus und MTA sind weiterhin verfügbar.
- Erwartete Spam- und Virenscan-Header sind, sofern zutreffend, weiterhin vorhanden.
- Die temporäre Debug-Protokollierung wurde wieder auf Normalbetrieb umgestellt.
- Jede benutzerdefinierte Regel oder Konfigurationsänderung wird dokumentiert, damit sie nach Aktualisierungen überprüft werden kann.
Offizielle Referenzen