Prestazioni Postfix

Esecuzione di postfix su Ubuntu, invio di posta (~ 1 milione di messaggi) al giorno. i carichi sono estremamente elevati ma non molto in termini di carico della CPU e di memoria. Qualcuno in una situazione simile e sapere come rimuovere il collo di bottiglia?

Tutta la posta su questo server è in uscita.

Dovrei presumere che il collo di bottiglia sia il disco.

Solo un aggiornamento, ecco come appare iostat:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

Questi numeri sono in linea con le prestazioni che ti aspetteresti da un singolo disco?

sdb è dedicato a postfix.

Penso che sia il mescolamento della coda, in arrivo-> attivo-> differito

Maggiori dettagli dalle domande:

Server: CPU quad core Xeon (R) E5405 @ 2.00GH con ram da 4 GB

Carico medio: 464,88, 489,11, 483,91, 4 core. ma l'utilizzo della memoria e la CPU sono minimi

Istanze Postfix tra 16 e 32

Questo può sembrare un po 'folle, ma dovresti:

1. Abbassa la registrazione al minimo indispensabile. Rendi solo syslog log mail.err o superiore.
2. Aggiungi più RAM. Sì, Postfix non ne ha bisogno, ma RAM aggiuntiva significa cache di pagina aggiuntiva per il kernel.
3. Non hai menzionato il filesystem su / dev / sdb (che conta anche un po '), ma sicuramente lo cambi a noatime, il che dovrebbe ridurre il carico almeno un po'.
4. Guarda quanto è grande il tuo / var / spool / postfix. Se è sotto un paio di concerti, considera di spostarlo su un ramdisk.

Non sono d'accordo con quelli che hanno suggerito di usare un disco RAM per "/ var / spool / postfix". Ciò significa che l'intera coda di posta verrà archiviata nella RAM. Se il tuo server si arresta in modo anomalo o perde energia, i messaggi in coda spariranno per sempre. Questo è davvero negativo dal punto di vista del cliente / utente perché il messaggio è già stato accettato con successo per la consegna. Peggio ancora, il tuo server non invierà un avviso in cui si afferma che un'e-mail è rimbalzata o non può essere recapitata perché la coda sarà vuota al riavvio del server.

Invece, aggiungerei tutti i dischi veloci che puoi permetterti; Non riesco davvero a stimare quanti ne avrai bisogno con le informazioni fornite. Dall'output "iostat" sopra, sembra che tu stia facendo ~ 120 IOPS su 'sdb' (somma di r / se w / s). È possibile stimare ragionevolmente che un singolo disco SCSI o FC da 15k RPM gestirà 150 IOPS. Vorrei iniziare con 5 dischi SCSI da 15k RPM e un controller RAID decente. Configuralo come RAID-10 su 4 unità con 1 hot spare. Non sono sicuro che questo risolverà completamente il tuo problema, ma sicuramente non lo farà peggiorare.

Esegui postfix con alcuni profiler (gprof?) O cerca nei registri. Postfix registra molte informazioni sui tempi che potrebbero dirti dove si trova il blocco. I luoghi comuni da guardare sono:

1. Prestazioni del disco. Potrebbe essere il momento di RAID-10 per la tua coda.
2. Qualsiasi tipo di I / O di rete sui messaggi. Blacklist DNS? SAV?
3. Milter e altri filtri che hai installato.
4. Ricerche di autenticazione e UID eseguite sulla rete o su un processo (ldap, sql).
5. non usando proxy: per mappe lente (come sopra)

Un milione di messaggi al giorno è di circa 11 al secondo, supponendo che il throughput sia costante. Postfix da solo dovrebbe essere in grado di gestire almeno un ordine di grandezza maggiore di quello sull'hardware del server entry-level. Quindi ho il sospetto che tu abbia più di un semplice postfix in esecuzione, o picchi di throughput distribuiti in modo molto irregolare.

La tua situazione sembra sicuramente un server fortemente associato a I / O. Questo è prevedibile con un MTA, che deve fare molte piccole scritture per garantire che non perda la posta.

Prenditi del tempo per ottimizzare l'I / O su entrambi /var/spool/postfixe /var/log. La migliore pratica per i server postfix occupati è quella di separare i due su diversi mandrini e assicurarsi che la registrazione asincrona sia abilitata. prefissa il nome del file di registro per il tuo registro di posta con un trattino su Linux.

mail.info                              -/var/log/mail.log

o simili.

Se stai usando amavisd-new, assicurati che l'area di lavoro sia su un filesystem tmpfs. Di solito lo indossiamo /tmp/vscan/. Questo è sicuro, poiché amavisd-new non restituisce una risposta di fine dei dati fino a quando l'hop a valle (post-filtro) non ha accettato il messaggio.

Alcune persone raccomandano le noatimeopzioni di montaggio per lo spool postfix. Questo è potenzialmente poco saggio, a causa del modo in cui postfix dipende dalla semantica del file system. Vedi ad esempio http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

Sembra sicuramente che il tuo sottosistema di dischi debba almeno essere considerato come parte del problema. A causa del modo in cui postfix mescola i file intorno a / var, suggerirei di cercare su Google "tweak ext3 filesystem" (almeno impostando noatime e writeback) per vedere se non è possibile migliorare le prestazioni a livello di filesystem.

Ho due cluster di server che raddoppiano il servizio DNS e SMTP in uscita per la posta elettronica destinata al cliente ed eseguono 250k messaggi ogni giorno (2k-10k / ora) senza nessun luogo vicino a quel tipo di bindup I / O.

A me sembra un collo di bottiglia dalle prestazioni di archiviazione.

Lo iowait di 99.88 ti dice che il tuo sistema sta trascorrendo molto tempo in attesa di archiviazione.

Sono d'accordo con Bill Weiss. Dovresti esaminare una configurazione raid10 per la coda.

o inizia con

vmstat 1

Anche "iostat 1" suggerito da moshen è buono

dal tuo sottosistema disco chiaramente più veloce sarebbe bello. raid-10 su 6-8 dischi da 15k rpm forse con un po 'di cache, un paio di concerti di memoria integrati.

monta la tua directory di spool con noatime, nodiratime opzioni. valuta la possibilità di ottimizzare o modificare il tuo file system per gestire molti file di piccole dimensioni [presumo].

Brian

Devi davvero ottenere un disco più veloce o preferibilmente passare a una soluzione di raid. Che tipo di server è questo?

Giacomo

Se si esegue amavis per il filtro antispam + virus, è necessario aumentare il numero di processi simultanei di amavis. In base all'impostazione, potrebbe essere necessario aumentare sia il numero di processi smtp-amavis da postfix master.cf sia l'impostazione relativa in amavis.conf.

Quanti core ci sono nella scatola e qual è il carico effettivo? Qual è la tariffa effettiva che stai ricevendo i messaggi inviati?

Come la maggior parte, il mio primo pensiero è il disco, quindi controlla quello.

Tuttavia, l'utilizzo della rete potrebbe essere la causa, così come il carico di interrupt elevato (scheda errata?), Quindi controlla quelli. Ho scoperto che anche per un server di posta modesto, avere un server DNS con memorizzazione nella cache veloce (sono parziale a "non associato") nella stessa casella aiuta ad alleviare la latenza e il carico della rete.

con te che fai 630 letture e 1042 scritture al secondo, suggerisco decisamente di aumentare la memoria del sistema (per gestire meglio il sistema operativo e un'unità RAM) e quindi rendere la tua cartella postfix un ramdisk.

Suggerirei anche di inserire i registri di posta nella propria partizione, se non nel proprio disco.

Questo non è un problema di I / O, è un problema di configurazione postfix. Lo stai chiedendo di fare troppo tutto in una volta e creare un collo di bottiglia per te stesso. Controlla il readme di ottimizzazione delle prestazioni postfix e / o pubblica il tuo main.cf in modo che possiamo aiutarti.

sembra che tu abbia un disco instabile. Il tuo server esegue solo 72 richieste di lettura / sec e 42 di scrittura / secondi. L'HDD desktop Seagate 7200 RPM è in grado di eseguire oltre 100 richieste di lettura / scrittura casuali al secondo e comunque di farcela.

Prova a montare la bobina su sda e vedi se il carico migliora.

Ma prima di sprecare più soldi sul disco, procedi come segue:

1. Esegui qshape attivo, qshape differito e qshape in arrivo e facci sapere il totale di ciascun comando.

   Un numero insolitamente elevato di posta nella coda posticipata indica che il tuo server di posta potrebbe essere utilizzato dallo spammer per inoltrare il proprio spam (ad es. Invio di posta elettronica a un dominio inesistente che farà riprovare ripetutamente il tuo postfix).

2. Assicurati che il tuo server di posta non sia nella lista nera ( http://www.mxtoolbox.com/blacklists.aspx )

3. Controlla il tempo di risposta DNS ed esegui una cache DNS locale.

   Il server di posta utilizza DNS piuttosto pesantemente. Do dig somedomain.com mx Run sopra pochi host differenti. Generalmente il tempo di risposta dovrebbe essere inferiore a 100 - 400ms. Se ricevi una risposta più elevata, il tuo DNS potrebbe non funzionare bene. Prova DNS diversi (potresti provare 8.8.8.8 o OpenDNS di Google: 208.67.222.222)

4. Controlla la tua rete. (ad es. ifconfig) e vedere quanti pacchetti di errori. Controlla se il tuo link è saturo o modellato. Controlla se c'è stato un numero elevato di operazioni di timeout nei registri di posta. Fare tcpdump e assicurarsi che i pacchetti non vengano persi o ritrasmessi.

5. Puoi dirci se la console è reattiva (ad es. Quando si digita un comando quanto velocemente il sistema ti dà feedback)?

   Generalmente un problema di rete (ad es. DNS) provoca un aumento vertiginoso del carico, ma il sistema è ancora reattivo.