Newsgroup: it.comp.os.linux.sys
Titolo: sovraccarico server di posta

E' da qualche giorno che verso le 12 si verifica un sovraccarico del server 
di posta (postfix 2.8.2, centos 5.8 in virtuale su xen 6.0.2, 16 gb di ram e 
san in fibra)
L'ideale sarebbe discriminare gli utenti che si autenticano (sasl di 
dovecot) dai server remoti: limitare i secondi per far andare meglio i 
primi.
Come posso fare?
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 Come posso fare?
 
Capito fava. :-D
Riesplica.
 
Definendo
 
1) ruolo del "server di posta" (MSA? MTA? LDA? Tutto? Altro?)
 
2) in cosa consiste il "sovraccarico" (iowait a palla? CPU a tappo?
Processi di postfix a saturazione? Altro?)
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 
 
 

 Processi di postfix a saturazione? Altro?)
cpu con load oltre 50 (anche punte di 150) probabilmente per iowait troppo 
alto (la fibra viaggia ma evidentemente non gli basta)
purtroppo centos 5.8 non vede oltre i 16 gb di ram.
 
La macchina è ben dimensionata per un carico standard (considera che son 
passato da un load di 60 alle 12.30 per arrivare adesso a load 1
 
Il server normalmente fa girare sui 250/300 processi contemporanei, nei 
momenti "topici" arriva a 1500
 
I 2 server (2 fujitsu rx300 con 48 gb di ram cadauno) non mostrano poi quei 
grandi affaticamenti.


 passato da un load di 60 alle 12.30 per arrivare adesso a load 1
 
giusto per capire:
 
http://video.tosnet.it/oggi.png
 


 momenti "topici" arriva a 1500
 
Dovresti cercare di capire quali sono i processi che causano quel
carico. Già il fatto che tu dica "*probabilmente* per iowait troppo
alto" significa che non hai in funzione il monitoraggio sufficiente a
capire che sta realmente accadendo (mi permetto di consigliare vivamente
munin al riguardo, ma puoi ottenere gli stessi risultati con diversi
sistemi di monitoraggio...).
 
 
Se effettivamente si tratta di risorse di I/O insufficienti, a causare
il troppo I/O può essere a causa dei servizi SMTP o IMAP. Se si tratta
di IMAP, è possibile che tu possa fare del tuning e ottimizzare l'I/O
(soprattutto dovecot >= 1.2 ha parecchie configurazioni utili, al
riguardo). Se si tratta di SMTP, può essere per I/O verso disco o per
I/O verso rete (eccessive latenze nei lookup DNS, motore antispam non
tunato e/o inadatto al tuo carico, ecc).
 
Ma fin quando non sei in grado di dire dove sta il problema è difficile
ipotizzare dove andare a cercare una soluzione...


 
-- 


 io penso sia un problema di i/o disco verso la san
 
Poesse, ma mancano i dati per dirlo.
Però per riuscire a mettere in difficoltà una macchina (e una SAN) con
l'I/O generato dalle code delle mail il flusso di mail deve essere
davvero *molto* alto...


 E' da qualche giorno che verso le 12 si verifica un sovraccarico del server
 
perche' succede questo? nel senso perche' a mezzogiorno c'e' il picco?
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 
Appena riesco a installare munin....


 Ciao Jack
si, verso quell'ora succede il finimondo (più o meno) 
Appena lasciato tranquillo il server si mette in pari (max 10 minuti) e poi 
tutto ok


 tutto ok
 
ma perche' succede il finimondo? Tutti gli utenti si collegano
contemporaneamente? C'e' roba in batch che parte a mezzogiorno? cosa?
 
Perche', visto che e' un server di posta, io mi aspetterei dei picchi di
lavoro la mattina quando tutti iniziano a lavorare e dopo la pausa
pranzo, non quando la gente se ne va a pranzo.


 pranzo, non quando la gente se ne va a pranzo.
 
Concordo in pieno.
 
E giusto per complicare un pò la situazione, valuta se il carico deriva 
da qualcosa fuori da quel server. Mi spiego.
 
O a quell'ora tu ricevi un botto di connessioni perchè c'è qualcuno che 
si diverte a buttarti giù tutto (non si può escludere ma lo risolvi 
facilmente con iptables e lo controlli altrettanto facilmente con netstat) 
oppure hai degli altri colli di bottiglia esterni.
 
Mi pare di capire che usi un server host e questo di posta è un guest 
(xen? vmware?). Se il limite ce l'hai sull'i/o non è che la SAN è 
saturata da qualche altra istanza virtuale di qualche altro server ?
 
Non è che in quel frangente hai il database ultracarico ?
Come dice skull, non è che i problemi sono di risoluzione ed il DNS in 
quel momento ha problemi di sovraccarico ?
 
Leggo che usi quel server per inviare: quante mail hai in coda durante i 
picchi ? 
Non è che a mezzogiorno qualche furbo si diverte a matterti in coda 1000 
email e clamav/spamassassin impazziscono dal carico ?
 
Insomma, hai un pò di idee su cui lavorare.
 
Max

 Max


 improbabili.. ed il carico è passato da 30 a 8
 
Aheccolo.
Dovecot autentica su DB, per caso?
 
In tal caso hai probabilmente trovato il colpevole...
 
per segar fuori quella roba lì puoi usare fail2ban, facendo attenzione
però al fatto che poi ti possono capitare utenti che si segan fuori da
soli per le ragioni più svariate.
 
 
Un altro modo (piuttosto fantasioso, lo ammetto) tuttavia, è metterci
davanti perdition O:-)
 
Il senso è: esegui in modo schedulato (o ad ogni aggiunta/rimozione di
utente, se puoi) una esportazione degli utenti esistenti dal DB, e usi
la lista così creata per generare una hashmap che associa l'utente al
server IMAP, sulla porta (ad "accesso riservato") dove decidi di
configurarlo.
Tale mappa la dai in pasto a perdition, che pubblichi al posto di IMAP.
 
In tal modo tutti i lookup verso utenti inesistenti vengono segati da
perdition sulla base di un semplice lookup su un file .db, mentre
dovecot verrà chiamato in causa solamente per quegli utenti che esistono
davvero.
 
 
Questo ti consente di eseguire fail2ban con limiti molto alti, senza che
comunque i bruteforce "sotto soglia" ti causino problemi (per mettere in
difficoltà perdition su 'sta roba ce ne serve...)
 
 
[poi si può certamente ottenere lo stesso risultato in altro modo, ma io
perdition lo ho ugualmente per altre necessità e questa qui assicuro che
funziona benone...]


 soli per le ragioni più svariate.
L'ho installato ora, vedo cosa viene fuori.
Se l'utente sbaglia la password 20 volte e non se ne accorge 'zzi sua :)


 
 
Mi sto alterando..
Ho isntrallato fail2ban, centos mi ah giustamente caricato anche iptables..
Ho fatto la regexp e dai log funziona, faccio un
root@mx:/etc/fail2ban/action.d# iptables -L
 
e ottengo:
 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-dovecot-pop3imap  tcp  --  anywhere             anywhere            
tcp dpt:pop3
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 
Chain fail2ban-dovecot-pop3imap (1 references)
target     prot opt source               destination
DROP       all  --  
mx.zonda.com
         anywhere
DROP       all  --  183.7.88.100         anywhere
RETURN     all  --  anywhere             anywhere
root@mx:/etc/fail2ban/action.d# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-dovecot-pop3imap  tcp  --  anywhere             anywhere            
tcp dpt:pop3
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 
Chain fail2ban-dovecot-pop3imap (1 references)
target     prot opt source               destination
DROP       all  --  
mx.zonda.com
         anywhere
DROP       all  --  183.7.88.100         anywhere
RETURN     all  --  anywhere             anywhere
 
quindi dovrebbe andare: perché sto tizio sta continuando a loggarsi (o 
almeno ci prova) anche se è nella drop?


 almeno ci prova) anche se è nella drop?
 
Sicuro stia arrivando proprio e solo in pop3 e non pop3s, imap, imaps? O:-)


 
 
Si, quel server fa solo pop3..


 Si, quel server fa solo pop3..
 
Allora prova con un iptables -L -nv che magari ci dice qualcosa in più
(a partire dai contatori delle hits)


 (a partire dai contatori delle hits)
 
Magari anche conntrack -L | grep <ip_dello_stronzo> potrebbe dirci qualcosa.
 
 

 
 
Trovato... i log erano quelli di dovecot ma la connessione era tramite la 
sasl di dovecot per postfix, quindi passavano "di la"
adesso è fuori ;)


 improbabili.. ed il carico è passato da 30 a 8
 
Un singolo IP ti porta il carico da 8 a 30?
Per me hai qualcosa che non va nella configurazione di dovecot, a me succedeva lo stesso poi mi sono accorto di avere un numero di processi forkabili un po..... improbabile (svariate migliaia, mi era scappato uno zero di troppo).
 
Ho messo circa 200 ed ora durante i picchi son passato da 90 di load (anni fa postai l'output di top) a meno di 4.

 fa postai l'output di top) a meno di 4.
 
 
come pop3-login c'č il limite  a 32
Mi sa che c'č il default per il numero di processi, quindi 100.
non č una cifra eccessiva


 non è una cifra eccessiva
 
no, non è eccessivo.
hai messo un limite alle connessioni da singolo ip ? Dovecot permette di farlo senza scomodare iptables.