Newsgroup: it.comp.os.linux.sys
Titolo: postfix e mysql


Pensavo fosse un problema di timeout di mysql, ma la variabile 
wait_timeout é impostata a 28800, quindi il problema non dovrebbe essere 
questo..
Idee?
g4b0, linux user n. 369000
http://brosulo.net

 problemi per cui il tuo server non regge. Verifica.
Ha iniziato a darmi questi problemi lunedí, dopo aver fatto tuning su 
my.cnf. Non capisco peró dove ho sbagliato, gli ho semplicemente dato 
piú risorse...
Che parametri di mysql posso controllare?
-- 


 Idee?
Cambiare DBMS?

 problemi per cui il tuo server non regge. Verifica.
Ecco le modifiche:
#table_cache            = 40 # vecchia configurazione
table_cache            = 2048
query_cache_limit       = 512k # configurazione 20100419 (prima non era 
impostato)
#query_cache_size        = 1M # vecchia configurazione
query_cache_size        = 2M # configurazione 20100419
#max_heap_table_size = 32M #vecchia configurazione
max_heap_table_size = 50M # configurazione 20100419
#tmp_table_size = 32M #vecchia configurazione
tmp_table_size = 50M # configurazione 20100419
Ho portato la query_cache_limit a 1M, anche se mi fa strano che mysql 
non ce la faccia, é un server con pochissimo traffico...
-- 


 Cambiare DBMS?
Praticamente impossibile :) Cosa consiglieresti?
-- 


 piú risorse...
spesso dare più cache comporta più danni.
la domanda è: perché toccare qualcosa che funzionava?
-- 
give it away

 non ce la faccia, é un server con pochissimo traffico...
Riporta tutto ai parametri di default, fai andare il DB per diversi
giorni in produzione e poi dai una occhiata a MySQLTuner e vedi se e
come ti propone di variare i parametri:
http://mysqltuner.com/
-- 
Alessio


É un server low-traffic semi-casalingo che oltre a mysql, postfix ed 
amenitá varie ha anche apache con alcuni vhost.
Si tratta di un RPS di ovh con accesso al disco molto lento, per cui i 
siti con accesso al DB ci mettevano molto a caricare. Aumentando la 
cache ho velocizzato i siti, ma mi trovo con questo problema di postfix.
In realtá le mail arrivano, ma non al primo giro. Vengono messe in queue 
  e poi passano. Ne ho perse solo 3 i 4 giorni.
Perché dare più cache comporta più danni?



É proprio mysqltuner che mi ha consigliato queste modifiche :)


 Praticamente impossibile :) Cosa consiglieresti?
Qualsiasi altro tra quelli supportati :)

 non ce la faccia, é un server con pochissimo traffico... 
Se è un server database che usi solo per fare il lookup da postfix,
delle cache puoi anche fregartene.
La query più grossa che farai mai sarà una select che impiegherà un
nanosecondo a risolvere, anche leggendo da disco. Sempre che tu non
stia gestendo gmail.
Il "mysql server has gone away" è sempre dato da un errore di timeout.
Apri la connessione, non fai niente per un tot di tempo, mysql chiude
la connessione e l'altra estremità appena prova a comunicare sul canale
aperto in precedenza se lo ritrova chiuso.
l'interactive_timeout a quanto è impostato? AFAIR il wait_timeout può
essere solo inferiore al quello interactive. Se l'interactive è
impostato a 100 (per dire) ed il wait a 1000, dopo 100 secondi ti
ritrovi comunque la connessione chiusa.
E poi, sicuro di aver ricevuto posta nelle ultime 8 ore?
Io su server poco trafficati portavo i timeout a 24 ore, tanto in questo
caso avere *una* connessione in più non da fastidio.
Stai proxando le query con postfix? (proxy:mysql:...), mi pare che
così facendo postfix ti cache le richieste, fa meno query, quindi il
server va in timeout.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Perché dare più cache comporta più danni?
The usual approach to setting MySQL’s table cache size is to make it large 
enough that it can hold all of your tables open, but we have too many tables 
for that to be practical. Instead, we decided to make it big, to improve the 
odds that tables we need were already in the cache. And since we had new, 
bigger hardware with more RAM and faster disks, we decided to cache even 
more tables.
Unfortunately, while opening tables is fast in MySQL, the speed at which it 
can close tables gets slower and slower as the table cache grows. Linearly, 
in fact. And since the cache will always end up full, the speed that MySQL 
can close tables becomes the speed that MySQL can open tables. And to 
exacerbate the problem, opening and closing tables in MySQL uses a global 
lock, so only one thread can be opening or closing tables at a time, 
regardless of how many threads are executing in parallel.
Once we understood this, we realized that if the cache is going to be full, 
it needs to be kept as small as possible. We reduced it to the minimum we 
could get away with without having to reopen tables in the middle of one 
session interacting with FreshBooks. And now that closing tables is faster, 
everything’s faster.
-- 
give it away

 everything’s faster.
Interessante.. e alquanto strano! É un problema tipico di mysql o ce 
l'hanno anche altri RDBMS?


 server va in timeout.
Questo potrebbe essere un motivo, ma non mi quadrano comunque i tempi 
del log di cui sopra..


 del log di cui sopra..
Probabilmente se disattivi il proxy non dovresti aver problemi.


 Probabilmente se disattivi il proxy non dovresti aver problemi.
E come si fa? :)
# more 
main.cf
 | grep proxy
virtual_alias_maps = proxy:mysql:/etc/postfix/
mysql-virtual_forwardings.cf
,
virtual_mailbox_domains = proxy:mysql:/etc/postfix/
mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/
mysql-virtual_mailboxes.cf
transport_maps = proxy:mysql:/etc/postfix/
mysql-virtual_transports.cf
virtual_mailbox_limit_maps = 
proxy:mysql:/etc/postfix/
mysql-virtual_mailbox_limit_maps.cf
proxy_read_maps = $local_recipient_maps $mydestination 
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps 
$virtual_mailbox_domains $relay_recipient_maps $relay_domains 
$canonical_maps $sender_canonical_maps $recipient_canonical_maps 
$relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps



Il numero di connessioni?
Accedi a mysql tramite il servizio proxy?
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 Accedi a mysql tramite il servizio proxy?
Il numero di connessioni a mysql é < a max_connections, e si, accedo 
tramite proxy:
# more 
main.cf
 | grep proxy
virtual_alias_maps = proxy:mysql:/etc/postfix/
mysql-virtual_forwardings.cf
,
virtual_mailbox_domains = proxy:mysql:/etc/postfix/
mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/
mysql-virtual_mailboxes.cf
transport_maps = proxy:mysql:/etc/postfix/
mysql-virtual_transports.cf
virtual_mailbox_limit_maps = 
proxy:mysql:/etc/postfix/
mysql-virtual_mailbox_limit_maps.cf
proxy_read_maps = $local_recipient_maps $mydestination 
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps 
$virtual_mailbox_domains $relay_recipient_maps $relay_domains 
$canonical_maps $sender_canonical_maps $recipient_canonical_maps 
$relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
Per eliminare il proxy mi basta togliere la direttiva 'proxy' (quella 
prima del : per intenderci) da virtual_alias_maps, 
virtual_mailbox_domains ecc?


 virtual_mailbox_domains ecc?
si.

 virtual_mailbox_domains ecc?
Sì. Ma ha l'effetto di martellare il DB, con ogni istanza di smtpd che
effettua la connect per i fatti suoi.
Sconsigliato, in linea di massima.


 Sconsigliato, in linea di massima.
Vero, ma almeno hai un potenziale problema in meno da dover debuggare.
Se con il proxy la connessione va in timeout, io provereri a togliere
il
proxy per qualche giorno e vedere se si ripresenta la problematica.
Se non dovesse ripresentarsi, il problema è il proxy. In tal caso,
sarebbe
opportuno aumentare ulteriormente il timeout delle connessioni mysql.

 Sconsigliato, in linea di massima.
Capito. Dato che si tratta di un server low-traffic forse é meglio 
aumentare il wait_timeout di mysql a 24h? Almeno una mail al giorno 
passa (mi faccio spedire il log di pflogsumm tutti i giorni :))


 opportuno aumentare ulteriormente il timeout delle connessioni mysql.
Ho riportato il parametro query_cache_limit di mysql al suo default (1M, 
lo avevo messo a 512K poco prima di avere il problema con postfix) e non 
ho ancora avuto problemi dal riavvio del server (mysql), avvenuto alle 
11:40. Nel frattempo non ho riavviato postfix e sono transitate delle 
email correttamente.
s1:/etc/postfix# postfix status
postfix/postfix-script: the Postfix mail system is running: PID: 21034
s1:/etc/postfix# ps aux | grep 21034
root     21034  0.0  0.3   5616  1532 ?        Ss   10:45   0:00 
/usr/lib/postfix/master
MYSQL SBARELLA?


 MYSQL SBARELLA?
Be, questo è un dato di fatto.


 email correttamente.
Per la cronaca, nessun problema ancora oggi, e sono passate parecchie 
mail...
