Quando un amavisdprocesso raggiunge o si avvicina al 100% di utilizzo della CPU, l'obiettivo non è semplicemente quello di farlo scomparire. Una soluzione efficace dovrebbe ripristinare il normale flusso di posta, ridurre la latenza di elaborazione, mantenere attivi i sistemi di protezione antispam e antivirus e impedire che la coda di Postfix continui a crescere.
In Zimbra, Amavisd-New si trova tra l'MTA e gli scanner di contenuti. La guida di amministrazione di Zimbra Daffodil attualmente in uso descrive Amavisd-New come l'interfaccia tra l'MTA di Zimbra, ClamAV e SpamAssassin. Ciò significa che un picco di utilizzo della CPU può derivare da Amavis stesso, dalle regole di SpamAssassin o dal contenuto dei messaggi, dalla scansione antivirus o da un backlog che tiene occupati tutti i worker disponibili. Consultare la Guida di amministrazione di Zimbra Daffodil .
Un esito positivo si manifesta con quattro segnali: l'utilizzo della CPU di Amavis si riduce a un livello sostenibile, le code dei messaggi differiti e attivi smettono di aumentare, i nuovi messaggi vengono elaborati senza ritardi anomali e i servizi antispam/antivirus rimangono funzionanti. Se l'utilizzo della CPU diminuisce solo perché il filtro è stato disabilitato, significa che il problema di fondo non è stato risolto.
Iniziate dal livello del sistema operativo. Non date per scontato che la responsabilità sia di Amavis solo perché la consegna della posta è lenta. Controllate i processi più impegnati e verificate se uno o più amavisdprocessi stanno costantemente consumando un intero core della CPU.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Didascalia: Vista del terminale in cui amavisd è il principale consumatore di CPU, condizione da verificare prima di modificare le impostazioni di Zimbra.
Un breve picco di utilizzo della CPU può essere normale durante la scansione di un messaggio di grandi dimensioni o di un allegato compresso. Considerare il problema come persistente quando lo stesso sintomo si ripresenta con l'aumento dei ritardi nella posta o della profondità della coda. Verificare anche il carico medio, la memoria libera, l'attività di swap e i tempi di attesa I/O. Un utilizzo elevato della CPU con forte swap o contesa di storage potrebbe richiedere un'indagine più approfondita a livello di host, anziché una semplice modifica in Amavis.
Passa all'account Zimbra e verifica lo stato del servizio. La documentazione di Zimbra utilizza zmcontrol statuscome controllo standard per i servizi abilitati.
su - zimbra
zmcontrol status
zmamavisdctl status
Didascalia: Stato del servizio Zimbra che mostra i componenti Amavis, antispam, antivirus e MTA in esecuzione prima dell'inizio della risoluzione dei problemi.
Questo passaggio è importante perché "CPU al 100%" e "servizio non disponibile" rappresentano modalità di errore diverse. Se Amavis non è in esecuzione, indagare invece sugli errori di avvio. Se Amavis è in esecuzione ma saturo, continuare con l'analisi della coda e dei log.
La profondità della coda indica se l'elevato utilizzo della CPU sta influenzando la consegna. Consultare la documentazione di Zimbra sulla risoluzione dei problemi relativi zmqstatalle code per i conteggi dei messaggi e i comandi di Postfix per i dettagli sui messaggi. Eseguire i controlli ripetutamente a intervalli di pochi minuti.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Didascalia: Le statistiche delle code e i messaggi differiti forniscono una misura più accurata dell'impatto sul flusso di posta rispetto alla sola percentuale di utilizzo della CPU.
Cercate di individuare una tendenza, non un singolo valore isolato. Una coda che aumenta a ogni campionamento significa che la velocità di elaborazione è inferiore alla velocità di arrivo. Una coda che diminuisce costantemente dopo una modifica è uno dei segnali più evidenti che la modifica ha effettivamente apportato benefici.
Se si esegue una distribuzione multi-MTA, verificare specificamente il nodo MTA interessato. Non dare per scontato che la coda su un altro nodo rifletta lo stesso collo di bottiglia.
I messaggi di risoluzione dei problemi di Amavis e SpamAssassin vengono scritti in /var/log/zimbra.log. Cerca intorno al momento del picco di utilizzo della CPU e correla gli ID dei messaggi, gli ID dei processi e la durata delle scansioni.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Didascalia: Le righe di registro di Amavis e SpamAssassin possono rivelare se i singoli messaggi o le fasi di scansione impiegano un tempo insolitamente lungo.
Tra i modelli utili si annoverano scansioni SpamAssassin lunghe e ripetute, tentativi ripetuti per gli stessi ID di coda, errori di comunicazione con ClamAV, errori relativi alla decompressione o un piccolo insieme di messaggi che consumano ripetutamente i processi. La documentazione di Zimbra sulla risoluzione dei problemi raccomanda specificamente di utilizzare la registrazione di debug di Amavis e SpamAssassin quando i ritardi nelle scansioni interrompono il flusso di posta. Consultare la documentazione di Zimbra sulla risoluzione dei problemi di registrazione .
Zimbra offre controlli di logging separati per Amavis e SpamAssassin. Il livello di logging documentato per Amavis va da 0 a 5, mentre per SpamAssassin zimbraAmavisSALogLevelsi utilizzano i valori 0 o 1. Si consiglia di iniziare con il livello 2 di Amavis anziché con il livello di dettaglio massimo, a meno che non sia necessario un debug più approfondito.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Didascalia: Le modifiche temporanee ai log rendono più facile correlare i tempi di scansione e il comportamento di SpamAssassin con il picco di utilizzo della CPU.
Riproduci o osserva il problema solo per il tempo necessario a raccogliere dati utili. Un livello di registrazione più elevato comporta un aumento delle scritture su disco e può rendere un server già occupato più rumoroso. Dopo l'indagine, ripristina i valori precedenti; Zimbra documenta che il livello di registrazione predefinito di SpamAssassin è 0 e quello di Amavis è normalmente a basso volume.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1Se i log indicano costantemente SpamAssassin come causa del problema, verifica se questo è iniziato dopo una modifica delle regole, l'implementazione di una regola personalizzata o un aggiornamento delle regole non riuscito. Espressioni regolari progettate male e regole problematiche possono risultare onerose per determinati corpi dei messaggi.
Il materiale ufficiale di Zimbra per la risoluzione dei problemi relativi ad Amavis documenta il comando di aggiornamento di SpamAssassin incluso in ZCS 8.8 e versioni successive come segue:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Didascalia: L'aggiornamento delle regole SpamAssassin incluse nel pacchetto è opportuno quando i log o gli errori di avvio indicano dati delle regole obsoleti o danneggiati.
Non considerarlo sa-updateuna soluzione universale per la CPU. Se il picco è iniziato subito dopo l'aggiunta di una regola personalizzata, testa prima quella regola. Zimbra memorizza le regole personalizzate di SpamAssassin più recenti in /opt/zimbra/data/spamassassin/localrules/. Rimuovi o disabilita solo la personalizzazione sospetta durante una finestra di manutenzione controllata, quindi confronta i tempi di scansione e il comportamento della coda.
La wiki ufficiale di Zimbra segnala anche le impostazioni di aggiornamento automatico delle regole e di compilazione per le versioni più recenti di ZCS. Prima di abilitare il comportamento automatico su un server già esistente, si consiglia di consultare le strategie antispam di Zimbra .
Un riavvio può sbloccare i processi in esecuzione e caricare le regole aggiornate, ma dovrebbe essere eseguito dopo la diagnosi, non in sostituzione di essa. Riavviare prima solo Amavis, a meno che le evidenze non indichino un problema all'intero stack MTA.
su - zimbra
zmamavisdctl restart
Didascalia: Il riavvio di Amavis ricarica il servizio dopo una modifica mirata delle regole o della configurazione, senza riavviare inutilmente tutti i servizi di Zimbra.
Se l'utilizzo della CPU torna immediatamente al 100%, si tratta di un'indicazione utile: la causa è ancora presente. Consultare nuovamente i log e verificare se lo stesso messaggio, scanner o regola si ripresenta. Riavviare ripetutamente il servizio può ridurre temporaneamente i sintomi, consentendo al contempo alla coda di crescere.
Non considerate l'incidente risolto solo perché avete visto un valore di CPU inferiore una volta. Verificate contemporaneamente il carico del processo, la direzione della coda e lo stato del servizio.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Didascalia: Il ripristino è più efficace quando l'utilizzo della CPU, la profondità della coda e lo stato del servizio Zimbra migliorano contemporaneamente.
Invia quindi un messaggio di prova tramite l'MTA interessato e verifica che venga consegnato entro il tuo normale intervallo di latenza. Per un messaggio che dovrebbe superare il filtro, controlla le sue intestazioni per i campi previsti dalla scansione antispam e antivirus di Zimbra/Amavis. Zimbra documenta intestazioni come X-Virus-Scannede X-Spam-Statusquando questi controlli sono attivi.
| Ciò che osservi | Migliore azione successiva | Perché |
|---|---|---|
| Un messaggio causa ripetutamente lunghe scansioni | Metti in quarantena o ispeziona quel messaggio in modo sicuro e correla il suo ID di coda con i log. | Il collo di bottiglia potrebbe essere legato al contenuto piuttosto che alla capacità. |
| Il timing di SpamAssassin domina | Esamina le regole personalizzate, gli aggiornamenti delle regole e l'output di debug. | I set di regole che fanno un uso eccessivo di espressioni regolari o che sono danneggiati possono rendere costoso il calcolo del punteggio. |
| Gli errori o i timeout di ClamAV sono predominanti | Indagare sullo stato di salute dell'antivirus e aggiornare lo stato | Amavis potrebbe semplicemente essere in attesa dello scanner che chiama |
| L'utilizzo della CPU è elevato, ma le code rimangono prossime allo zero. | Osserva più a lungo prima di apportare modifiche radicali. | Un elevato utilizzo può essere accettabile se la velocità di trasmissione e la latenza rimangono entro limiti accettabili. |
| Le code aumentano anche dopo le correzioni mirate | Escalation all'analisi della capacità, del modello di messaggio o del livello di supporto | Il server potrebbe essere sottodimensionato, sotto attacco o presentare un difetto specifico del software. |
Non disabilitare in modo permanente la scansione antispam o antivirus solo per ridurre il consumo di CPU. Zimbra supporta le policy di bypass per traffico specifico proveniente da fonti attendibili, ma ciò modifica il modello di sicurezza e dovrebbe essere una decisione deliberata relativa alle policy di posta, non una semplice ottimizzazione delle prestazioni. La documentazione di Zimbra relativa al bypass di SpamAssassin per il traffico in uscita chiarisce che il bypass è legato alle reti interne attendibili.
Evitate inoltre di aumentare indiscriminatamente il numero di worker di Amavis. Un numero maggiore di worker può incrementare la concorrenza, ma aumenta anche la pressione sulla memoria e potrebbe peggiorare la contesa della CPU. Il valore corretto dipende dal mix di messaggi, dalle dimensioni degli allegati, dal comportamento dello scanner, dai core disponibili, dalla memoria e dall'I/O. Testate le modifiche in base alla velocità di elaborazione e alla latenza della coda, anziché presumere che un pool di worker più ampio sia necessariamente più veloce.
Questa procedura è pensata per il caso comune in cui Amavis è in esecuzione ma risulta costantemente limitato dall'utilizzo della CPU. Non sostituisce le linee guida di supporto Zimbra specifiche per la versione in caso di difetti del prodotto accertati, server compromessi, attacchi denial-of-service con messaggi non validi o architetture multi-nodo con scanner esterni.
La documentazione tecnica della community di Zimbra ha documentato casi storici in cui messaggi appositamente creati o comportamenti anomali di SpamAssassin potevano sovraccaricare la CPU dei worker di Amavis per periodi prolungati. Poiché l'entità del rischio dipende dalle versioni di Zimbra e SpamAssassin installate, non applicare ciecamente una vecchia procedura di aggiornamento del pacchetto. Innanzitutto, annota la tua versione di Zimbra zmcontrol -v, confrontala con la versione e il livello di patch supportati e segui le indicazioni del fornitore per gli aggiornamenti.
Confronta sei server e collettori syslog gratuiti per Windows e Linux, inclusi strumenti con interfaccia grafica, opzioni open source, funzionalità di ricerca, avvisi e trasporto sicuro.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
