Newsgroup: it.comp.os.linux.sys
Titolo: Monitor attività dischi

Ciao a tutti!
Ho dei grossi problemi su un Server Courier-Imap, nel senso che quando 20/30 
utenti aprono le loro grosse mailbox i tempi di attesa del servizio IMAP 
sono veramente lunghi; se digito ad esempio, telnet localhost 143 il socket 
si apre ma il banner dell'IMAP si apre dopo anche 1/2 minuti!
Siccome il consumo di CPU è quasi lo 0% e la RAM ha 8Gb e i dischi sono dei 
SAS a 15k, volevo sapere se qualcuno conosce qualche bel tool di bash per 
monitorare il workload dei dischi, in modo da vedere se il collo di 
bottiglia sta li.
GRAZIE!
Francesco 

 servizi di rete.
Anche a me puzza, il dubbio però che ho è che, quando è bloccato, come in 
questo momento (grrrrr), se da consolle faccio telnet localhost 143 è 
impiantato ugualmente... e non dovrebbe usare il DNS per risolvere 
localhost!
Inoltre l'ho spostato dalla DMZ alla LAN per evitare eventuali problemi di 
routing...
Il problema c'è soltanto quando molti utenti accedono, alla sera o pausa 
pranzo va benissimo...
Unica cosa rimasta: lo switch è a 100Mbp/s e non a 1000
Tu che cosa guarderesti?
Grazie, è un mese che ormai mi ci scorno dentro!
CIAO!!!
Francesco 

Aggiungo... Courier è lanciato con -H, dovrebbe evitare il lookup inverso 
nel DNS, ciao!
Ho anche alzato il valore softlimit...
Francesco
[root@mail imap4]# cat run
#!/bin/sh
HOSTNAME=`hostname --fqdn`
rm -rf ./env/*;
cat /etc/courier/imapd | /usr/bin/envconv
exec /usr/bin/envdir ./env/ \
/usr/bin/softlimit -m 18000000 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME 0 143 \
/usr/sbin/imaplogin \
/usr/bin/imapd Maildir 2>&1
[root@mail imap4]#

 pranzo va benissimo...
In che ordine di grandezza e` "molti"? 100, 10.000, 1.000.000?
Bye.

In che ordine di grandezza e` "molti"? 100, 10.000, >1.000.000?
Avrò si e no 20/30 utenti... infatti è stranissima la cosa...
Grazie! 

 bottiglia sta li.
Domandina: dove sono messe tutte le informazioni sugli utenti? In un DB?
Non e' che il collo di bottiglia e' proprio li?
E' un bel po' che non uso piu' Courier (ora uso Dovecot), ma mi sembra di
ricordare vagamente che il programma cerca di comunicare con il DB-Server
non solo DOPO l'autenticazione dell'utente, ma anche all'avvio della
connessione.
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Tu che cosa guarderesti?
intanto comincia a tenere un paio di shell aperte e dai una bella guardata
con iostat e vmstat per capire se quella che vedi e' attesa passiva (io
disco, ad esempio) oppure attesa attiva (i processi fanno qualcosa) poi,
con il top od il ps, guarda la colonna WCHAN che ti dice in quale
system-call il processo e' fermo.
puo' essere tante cose, anche la memoria piena o il kernel troppo 
aggressivo nell'io che surgela i processi mentre lavora sui dischi.

Ciao Davide e grazie!
La LAN č 100FD
eth0: negotiated 100baseTx-FD flow-control, link ok
Grazie!

 Avrò si e no 20/30 utenti... infatti è stranissima la cosa...
Allora guarda il file di config imapd, in particolare le opzioni:
MAXDAEMONS
MAXPERIP
Se hai 30 utenti metti un centinaio di daemons e 2 collegamenti per IP.
Se hai le impostazioni di default dovrebbero essere 40 e 2, quindi se gli 
utenti ricevono posta grossa o fanno speso il fetch potrebbero saturare 
courier.
ed eventualmente metti anche
TCPDOPTS="-nodnslookup -noidentlookup"
Cosi` eviti il reverse lookup.
Bye.

> Siccome il consumo di CPU č quasi lo 0% e la RAM ha 8Gb e i dischi sono 


possibilissimo esaurirle tutte.
Max_connections non esisteva nel mio my.cnf... gliele ho aggiunte, a 500.
Ciao!
Francesco 

 Fase 4. verificare che il problema sia risolto, se no, si
hai ragione... scusa!
MySQL mostra questo status:
mysql> status
--------------
mysql  Ver 14.12 Distrib 5.0.22, for redhat-linux-gnu (i686) using readline 
5.0
Connection id:          187
Current database:
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.0.22
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            /var/lib/mysql/mysql.sock
Uptime:                 11 min 4 sec
Threads: 25  Questions: 859  Slow queries: 0  Opens: 0  Flush tables: 1 
Open tables: 12  Queries per second avg: 1.294
Ciao! 

Eccoci qua:
[root@mail ~]# mysqladmin -u root -p processlist
Enter password:
+----+----------+-----------+----------+---------+------+-------+------------------+
| Id | User     | Host      | db       | Command | Time | State | Info 
|
+----+----------+-----------+----------+---------+------+-------+------------------+
| 2  | vpopmail | localhost | vpopmail | Sleep   | 279  |       | 
|
| 4  | vpopmail | localhost | vpopmail | Sleep   | 232  |       | 
|
| 5  | vpopmail | localhost | vpopmail | Sleep   | 232  |       | 
|
| 7  | vpopmail | localhost | vpopmail | Sleep   | 167  |       | 
|
| 8  | vpopmail | localhost | vpopmail | Sleep   | 75   |       | 
|
| 9  | vpopmail | localhost | vpopmail | Sleep   | 178  |       | 
|
| 16 | vpopmail | localhost | vpopmail | Sleep   | 11   |       | 
|
| 17 | vpopmail | localhost | vpopmail | Sleep   | 100  |       | 
|
| 24 | vpopmail | localhost | vpopmail | Sleep   | 75   |       | 
|
| 29 | vpopmail | localhost | vpopmail | Sleep   | 19   |       | 
|
| 30 | vpopmail | localhost | vpopmail | Sleep   | 21   |       | 
|
| 31 | vpopmail | localhost | vpopmail | Sleep   | 32   |       | 
|
| 32 | vpopmail | localhost | vpopmail | Sleep   | 31   |       | 
|
| 33 | vpopmail | localhost | vpopmail | Sleep   | 21   |       | 
|
| 37 | vpopmail | localhost | vpopmail | Sleep   | 8    |       | 
|
| 38 | vpopmail | localhost | vpopmail | Sleep   | 8    |       | 
|
| 39 | root     | localhost |          | Query   | 0    |       | show 
processlist |
+----+----------+-----------+----------+---------+------+-------+------------------+
Ciao! 

 200 connessioni aperte e mysql si blocca. Ora devi verificare l'idea.
Già.. potrebbe essere, ho messo max_connections=1000 ed è migliorato ma non 
del tutto... ci sono altri parametri da settare?
Inoltre... il valore: Queries per second avg: 1.268, è inteso in migliaia 
(milleduecentosessantotto) o in decimale (uno virgola 268)? Scusa il dubbio, 
ciaooo!
Francesco 

Aggiungo anche l'output di iostat che forse mancava... thanks! La partizione 
sda5 è quella dove sono le Maildir...
Franceso[root@mail ~]# iostat -x -p
                             extended device statistics
device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t 
%b
sda        0    11    1.1    5.6    42.8    66.6   16.3   0.5   77.9   3.5 
2
sda1       0     0    0.0    0.0     0.0     0.0    0.0   0.0    0.0   0.0 
0
sda2       0     0    0.0    0.0     0.0     0.0    0.0   0.0    0.0   0.0 
0
sda3       0     0    0.0    0.0     2.1    16.2    0.0   0.0    0.0   0.0 
0
sda4       0     0    0.0    0.0     0.0     0.0    0.0   0.0    0.0   0.0 
0
sda5       0     0    0.0    0.0    40.7    50.4    0.0   0.0    0.0   0.0 
0
[root@mail ~]#

>_se_ quello e' il problema, potresti cominciare a capire _perche'_ non
chiude le connessioni e magari se non e' un idea l'evitare mySql del
tutto.
Già... il problem è che uso QmailToaster ed il backend di autentica è su 
MySQL... però prima ho avuto un bottleneck da paura, e MySQL non mi sembrava 
fosse cotto... grazie!
Francesco 

 200 connessioni aperte e mysql si blocca. Ora devi verificare l'idea.
A me sembra abbastanza normale. Se ha impostato in imapd i parametri 
standard (40 daemon) e ha 30 utenti che accedono, quelle 39 connessioni 
sono assolutamente nella norma.
I processi sono in sleep perche` usano connessioni persistenti, in modo da 
evitare l'overhead della connessione se arrivano altre chiamate entro tot 
tempo, infatti il time massimo e` di 279 secondi (il che mi fa pensare a 5 
minuti di "mantenimento").
Le query, poi, sono piu` di una al secondo, il che ci dice due cose:
1- gli utenti fanno un polling forsennato della posta
2- la tabella degli utenti e` cachata in RAM, quindi i dischi non fanno 
quasi nulla
Insisto (per Francesco): aumenta il parametro MAXDAEMONS nella 
configurazione di imapd.
Bye.

 configurazione di imapd.
Attualmente sono a MAX_DAEMONS=600
Aumento ulteriormente?
GRAZIE! 

... Correggo:
ho aumentato da 45 a 200 i maxdaemons anche nel file 
/etc/courier/authlib/authdaemonrc
CIAO!
Francesco

 Attualmente sono a MAX_DAEMONS=600
Non so che versione di courier hai o se hai sbagliato a scrivere, ma sul 
mio il parametro va senza l'underscore.
Se l'hai scritto cosi` stai usando il parametro standard, cioe` 40.
Bye.

 TCPDOPTS="-nodnslookup -noidentlookup"
Già fatto!
Grazie, ciao!
Francesco

 mio il parametro va senza l'underscore.
Si, effettivamente era cosě: MAXDAEMONS avevo sbagliato a trascrivere... 
ciaoo!
Francesco 

 Sono circa sui 400 e 200, daemons e maxperip già da 15 gg... Ho
Metti il MAXPERIP a 4 o 5, non a 200.
A meno che le macchine della LAN non siano NATtate dietro un firewall e 
accedano tutte con lo stesso IP.
Bye.

Sembra, ma lo voglio dire piano!!!, che modificando:
i daemons nel file /etc/courier/authlib/authdaemonrc
Courier-IMAP non vada più in stallo...
A questo punto il problema erano gli authenticator...
Stiamo a vedere domani... ciao!
Francesco 

Ciao Alessandro e grazie ancora per tutto... ora sembra che ci siamo!
Mi č perņ successo un nuovo problema, da quando sembra ho alzato i daemons 
in authdaemonrc... per due volte tutte le autentiche, sia pop3 che imap, 
fallivano, ed ho dovuto riavviare il Server MySQL e qmailctl restart.
Potrebbe essere che c'erano troppi authdaemons?
Grazie! 

 restart.
Puo` darsi che gli authdaemon, se sono piu` delle connessioni possibili in 
MySQL, tengano occupate le connessioni disponibili e non ne permettano 
altre.
Prova a fare una "scaletta", per esempio 100 MAXDAEMONS in imapd, 200 
authdaemon in courier, 400 o piu` connessioni disponibili in MySQL.
Inoltre controlla i limiti di file per processo, perche` potrebbe essere 
che il kernel blocca MySQL dall'aprire altre connessioni perche` ha 
terminato i file apribili.
Bye.

>Inoltre controlla i limiti di file per processo, perche` potrebbe essere
che il kernel blocca MySQL dall'aprire altre connessioni perche` ha
terminato i file apribili.
Percaso il limite è 64?
Ho guardato questo:
[root@mail bits]# cat local_lim.h | grep THREADS
#define _POSIX_THREAD_THREADS_MAX       64
COme eventualmente posso aumentarli?
Grazie, ciao!
Francesco

 COme eventualmente posso aumentarli?
In /proc/sys/fs ci sono diversi parametri configurabili sul numero di file 
e di inode aperti.
Bye.

 
pure 10mbit non giustificano quelle latenze!

Tutto risolto raga!
Erano gli authenticator di authvchkpw.
Ciaooo!
Francesco