Când un amavisdproces se află la sau aproape de 100% din capacitatea procesorului, scopul nu este pur și simplu de a face acel proces să dispară. O soluție utilă ar trebui să restabilească fluxul normal de e-mail, să reducă latența de procesare, să mențină protecția antispam și antivirus funcțională și să împiedice creșterea continuă a cozii Postfix.
În Zimbra, Amavisd-New se află între MTA și scanerele de conținut. Ghidul actual de administrare Daffodil al Zimbra descrie Amavisd-New ca interfață între Zimbra MTA, ClamAV și SpamAssassin. Aceasta înseamnă că o creștere bruscă a solicitărilor CPU poate proveni de la Amavis în sine, din regulile sau conținutul mesajelor SpamAssassin, din scanarea antivirus sau dintr-o acumulare de sarcini care ține ocupați toți lucrătorii disponibili. Consultați Ghidul de administrare Daffodil al Zimbra .
Un rezultat pozitiv are patru semne: CPU-ul Amavis scade la un nivel sustenabil, cozile amânate și active nu mai cresc, mesajele noi trec fără întârzieri neobișnuite, iar serviciile antispam/antivirus rămân sănătoase. Dacă CPU-ul scade doar pentru că filtrarea a fost dezactivată, problema de bază nu a fost rezolvată.
Începeți la nivel de sistem de operare. Nu presupuneți că Amavis este responsabil doar pentru că livrarea e-mailurilor este lentă. Verificați cele mai aglomerate procese și confirmați dacă unul sau mai mulți amavisdworker consumă în mod constant un nucleu CPU complet.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Legendă: O vizualizare de terminal în care amavisd este consumatorul dominant de CPU, aceasta fiind prima condiție de verificat înainte de a modifica setările Zimbra.
Un vârf scurt poate fi normal în timp ce se scanează un mesaj mare sau un atașament comprimat. Tratați problema ca fiind persistentă atunci când același simptom continuă, în timp ce întârzierile la e-mail sau adâncimea cozii cresc. Verificați, de asemenea, media de încărcare, memoria liberă, activitatea de swap și așteptarea I/O. Volumul mare de procesor, cu conflicte mari de swap sau stocare, poate necesita o investigație mai amplă la nivel de gazdă, mai degrabă decât o modificare exclusivă la Amavis.
Comutați la contul Zimbra și verificați starea serviciului. Documentația Zimbra folosește zmcontrol statusca verificare standard serviciile activate.
su - zimbra
zmcontrol status
zmamavisdctl status
Legendă: Starea serviciului Zimbra afișează componentele Amavis, antispam, antivirus și MTA care rulează înainte de începerea depanării.
Acest pas este important deoarece „100% CPU” și „service down” sunt moduri de eroare diferite. Dacă Amavis nu rulează, investigați în schimb erorile de pornire. Dacă Amavis rulează, dar este saturat, continuați cu analiza cozii și a jurnalelor.
Adâncimea cozii vă spune dacă volumul mare al procesorului afectează livrarea. Materialul de depanare a cozii din Zimbra documentează zmqstatnumărul de cozi și comenzile Postfix pentru detalii despre mesaje. Rulați verificările în mod repetat la intervale de câteva minute.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Legendă: Statisticile cozii și mesajele amânate oferă o măsură mai bună a impactului asupra fluxului de e-mailuri decât procentul CPU în sine.
Căutați direcția, nu un număr izolat. O coadă care crește la fiecare probă înseamnă că debitul este sub rata de sosire. O coadă care scade constant după o modificare este unul dintre cele mai puternice semne că modificarea a ajutat cu adevărat.
Dacă rulați o implementare cu mai multe MTA, verificați în mod specific nodul MTA afectat. Nu presupuneți că coada de pe un alt nod reflectă același blocaj.
Mesajele de depanare Amavis și SpamAssassin sunt scrise în /var/log/zimbra.log. Căutați în jurul momentului vârfului de solicitare a procesorului și corelați ID-urile mesajelor, ID-urile proceselor și duratele scanării.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Legendă: Jurnalele Amavis și SpamAssassin pot dezvălui dacă mesajele individuale sau etapele de scanare durează neobișnuit de mult.
Printre modelele utile se numără scanări SpamAssassin lungi și repetate, încercări repetate pentru aceleași ID-uri de coadă, erori de comunicare ClamAV, erori legate de decompresie sau un set mic de mesaje care consumă în mod repetat worker-i. Documentația de depanare Zimbra recomandă în mod specific înregistrarea în jurnal a erorilor de depanare Amavis și SpamAssassin atunci când întârzierile de scanare perturbă fluxul de e-mailuri. Consultați referința de depanare a înregistrării în jurnal a Zimbra .
Zimbra expune controale separate de înregistrare în jurnal pentru Amavis și SpamAssassin. Intervalul Amavis documentat este de la 0 la 5, în timp ce zimbraAmavisSALogLevelfolosește 0 sau 1. Începeți cu nivelul 2 al Amavis, în loc de verbositate maximă, cu excepția cazului în care aveți nevoie de o depanare mai profundă.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Legendă: Modificările temporare ale înregistrării în jurnal facilitează corelarea timpului de scanare și a comportamentului SpamAssassin cu creșterea bruscă a consumului de energie al procesorului.
Reproduceți sau observați problema doar suficient de mult timp pentru a captura date utile. O înregistrare mai mare adaugă scrieri pe disc și poate face un server aglomerat mai zgomotos. După investigare, reveniți la valorile anterioare; Zimbra documentează nivelul implicit de înregistrare SpamAssassin ca fiind 0, iar înregistrarea Amavis ca fiind în mod normal de volum redus.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1Dacă jurnalele indică în mod constant către SpamAssassin, verificați dacă problema a început după o modificare a regulilor, o implementare personalizată a regulilor sau o actualizare eșuată a regulilor. Expresiile regulate proiectate necorespunzător și regulile problematice pot deveni costisitoare pentru anumite corpuri de mesaje.
Materialul oficial de depanare Amavis de la Zimbra documentează comanda de actualizare SpamAssassin inclusă pentru ZCS 8.8 și versiuni ulterioare astfel:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Legendă: Actualizarea regulilor SpamAssassin incluse este potrivită atunci când jurnalele sau erorile de pornire indică date de reguli învechite sau deteriorate.
Nu tratați sa-updateca o soluție universală pentru CPU. Dacă vârful de solicitare a început imediat după adăugarea unei reguli personalizate, testați mai întâi regula respectivă. Zimbra stochează regulile SpamAssassin personalizate moderne sub /opt/zimbra/data/spamassassin/localrules/. Eliminați sau dezactivați doar personalizarea suspectată într-o fereastră de întreținere controlată, apoi comparați timpul de scanare și comportamentul cozii.
Wiki-ul oficial Zimbra menționează, de asemenea, setările de actualizare automată a regulilor și de compilare pentru versiunile mai noi de ZCS. Consultați strategiile antispam Zimbra înainte de a activa comportamentul automat pe un server deja existent.
O repornire poate elimina lucrătorii blocați și poate încărca regulile actualizate, dar ar trebui să urmeze diagnosticarea, nu înlocuirea acesteia. Reporniți mai întâi doar Amavis, cu excepția cazului în care dovezile indică spre stiva MTA mai largă.
su - zimbra
zmamavisdctl restart
Legendă: Repornirea Amavis reîncarcă serviciul după o modificare specifică a regulilor sau a configurației, fără a reporni inutil toate serviciile Zimbra.
Dacă procesorul revine imediat la 100%, aceasta este o dovadă utilă: cauza este încă prezentă. Reveniți la jurnalele de lucru și identificați dacă același mesaj, scaner sau regulă apare din nou. Repornirea repetată a serviciului poate reduce temporar simptomele, permițând în același timp creșterii cozii.
Nu apelați incidentul ca fiind rezolvat după ce vedeți o dată un număr CPU mai mic. Verificați împreună încărcarea procesului, direcția cozii și starea serviciului.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Legendă: Recuperarea este mai puternică atunci când utilizarea CPU, adâncimea cozii și starea serviciului Zimbra se îmbunătățesc simultan.
Apoi trimiteți un mesaj de test prin MTA-ul afectat și confirmați că acesta este livrat în intervalul de latență normal. Pentru un mesaj care ar trebui să treacă de filtrare, inspectați anteturile sale pentru câmpurile de scanare anti-spam și anti-virus Zimbra/Amavis așteptate. Zimbra documentează anteturile, cum ar fi X-Virus-Scannedși X-Spam-Statuscând aceste verificări sunt active.
| Ceea ce observi | Cea mai bună acțiune următoare | De ce |
|---|---|---|
| Un mesaj provoacă în mod repetat scanări lungi | Puneți în carantină sau inspectați mesajul respectiv în siguranță și corelați ID-ul cozii sale cu jurnalele | Blocajul poate fi specific conținutului, mai degrabă decât legat de capacitate |
| Sincronizarea SpamAssassin domină | Examinați regulile personalizate, actualizările regulilor și rezultatele depanării | Seturile de reguli cu expresii regulate (Regex) sau deteriorate pot face ca scorarea să fie costisitoare |
| Erorile sau expirarile ClamAV sunt predominante | Investigați starea de sănătate și actualizarea antivirusului | Amavis ar putea pur și simplu să aștepte scanerul pe care îl apelează |
| CPU-ul este încărcat, dar cozile rămân aproape de zero | Observați mai mult timp înainte de a face schimbări disruptive | Utilizarea ridicată poate fi acceptabilă dacă debitul și latența rămân sănătoase |
| Cozile cresc chiar și după remedieri specifice | Escalarea către analiza capacității, a modelului de mesaje sau a nivelului de asistență | Serverul poate fi subdimensionat, atacat sau poate întâmpina un defect specific software-ului. |
Nu dezactivați permanent scanarea antispam sau antivirus doar pentru a reduce puterea procesorului. Zimbra acceptă politici de ocolire pentru trafic specific de încredere/originar, dar acest lucru modifică modelul de securitate și ar trebui să fie o decizie deliberată privind politica de e-mail, nu o modificare generică a performanței. Documentația Zimbra pentru ocolirea SpamAssassin originar precizează clar că ocolirea este legată de rețele interne de încredere.
De asemenea, evitați să creșteți orbește numărul de workeri Amavis. Mai mulți workeri pot crește concurența, dar cresc și presiunea asupra memoriei și pot agrava contenția CPU. Valoarea corectă depinde de mixul de mesaje, dimensiunea atașamentelor, comportamentul scanerului, nucleele disponibile, memoria și I/O. Testați modificările în funcție de debitul cozii și latența, în loc să presupuneți că un pool de workeri mai mare este mai rapid.
Această procedură este concepută pentru cazul obișnuit în care Amavis rulează, dar este persistent limitat de procesor. Nu înlocuiește îndrumările de asistență specifice versiunii Zimbra pentru un defect confirmat al produsului, un server compromis, o campanie de denial-of-service cu mesaje incorecte sau o arhitectură cu mai multe noduri și scanere externe.
Materialul tehnic al comunității Zimbra a documentat cazuri istorice în care mesaje special create sau comportamentul SpamAssassin ar putea lăsa lucrătorii Amavis limitați la utilizarea procesorului pentru perioade lungi de timp. Deoarece expunerea exactă depinde de versiunile de Zimbra și SpamAssassin instalate, nu aplicați orbește o rețetă veche de actualizare a pachetului. Mai întâi înregistrați versiunea Zimbra cu zmcontrol -v, comparați-o cu versiunea și nivelul de patch acceptate și utilizați îndrumările actuale ale furnizorului pentru actualizări.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
