MySQL too many connections: SOLUZIONE

Printable View

30-10-2003, 12.34.35

ne ho avuto la conferma facendo la query
SHOW VARIABLES
da phpMyAdmin (nnon credevo che un utente qualsiasi potesse emettere tale query comunque)

wait_timeout 28800

E' QUESTO il PROBLEMA.
QUESTA e' una FAQ.!
wait_timeout va assolutamente abbassato, da 30 a 300 secondi max.

Sysadmin di altervista documentatevi, basta cercare mysql e wait_timeout su google o il sito mysql o php.net
Non server far ripartire il server ogni tot per killare le connessioni idle
Neanche portare max_connections a 250 serve, 100 bastano

questo valore tiene aperte le connessioni per 8 ore, e se root fa la query
'SHOW PROCESSLIST' l e vede

PS
voglio 5000 (corretto;-) AC se il problema si risolve abbassando wait_timeout a 30.
Davvero.
In alternativa valuto proposte di lavoro, atualmente sono disoccupato ;-)

Sono sicuro al 100% che questo e' il problema
Non abbiate paura per il cpanel o il plesk, non influisce affatto

Grazie
30-10-2003, 13.38.54
Gianluca

tiki:

Apprezziamo l'interesse dimostrato, purtroppo attualmente non c'è la possibilità di assumere nessuno :)

La soluzione che hai descritto è appunto una faq, e ti posso assicurare che dietro ogni configurazione c'è una documentazione molto attenta, che va oltre alle semplici faq, ovvero si testa a lungo ogni variante in decine di condizioni differenti, poche configurazioni "sopravvivono" ad AlterVista.
Tempo fa si era testata anche una configurazione con wait_timeout più basso, parlo comunque di valori superiori a 30 secondi, ma tali impostazioni sono risultate inaccettabili in quanto determinate applicazioni necessitano di un wait_timeout consistente, non meno di 7200 secondi, almeno per ora.

Citazione:

Non abbiate paura per il cpanel o il plesk, non influisce affatto

AlterVista non poggia nè su cpanel nè su plesk, nè su altri software simili.
30-10-2003, 17.35.31

Citazione:

Originalmente inviato da Gianluca

tiki:

Tempo fa si era testata anche una configurazione con wait_timeout più basso, parlo comunque di valori superiori a 30 secondi, ma tali impostazioni sono risultate inaccettabili in quanto determinate applicazioni necessitano di un wait_timeout consistente, non meno di 7200 secondi, almeno per ora.

Ma quali? Manco se dovessi tenere in sync due database che stanno dalla parte opposta del mondo, hai bisogno di mantenere la stessa connessione persistente per 2 ore di inattività!
E poi, non e' che se la connessione va in timeout, la query successiva non viene evasa e si perde nel nulla
Semplicemente viene servita da un nuovo processo e con una nuova connessione..
Perdi solo il vantaggio della persistenza, ci vorra'' qualche millisecondo in piu' per la query successiva.
So di siti very busy che impostano wait_timeout anche a 15 secondi
Tra l'altro esiste un'altro parametro di timeout, per le connessioni batch, che puo' essere di valore diverso...
Boh! Contenti voi...

PS

Citazione:

non meno di 7200 secondi, almeno per ora.

SHOW STATUS mostra infatti che il server viene fatto ripartire molto meno che ogni due ore ;-) inutile un wait_timeout maggiore ;)
31-10-2003, 09.38.54

Non so se questa e' la vostra soluzione.

inviando la query da my_admin
SHOW STATUS

vedo che l'uptime, arrivato a 600, riparte da 0
in pratica il server mysql viene fatto ripartire ogni 5 minuti!

come faccio a farmi un backup che dura qualcosa in piu', me lo chiedo

In questa situazione, puoi tranquillamente abbassare wait timeout a 600, altro che 7200!
E quelle determinate applicazioni che necessitano di un wait_timeout consistente vanno a farsi benedire comunque.
Ciurli?

PS
ricordati i miei 5000 AC ;-)
Quando vedo che avete abbassato wait_timeout a qualcosa di decente ( e non avete altra soluzione), te li chiedo

puoi sempre disabiltare la query SHOW VARIABLES e SHOW STATUS per gli utenti se ti sidpiace il mio nteressamento
31-10-2003, 17.56.06
Gianluca

tiki:

non riesco a comprendere appieno la natura del tuo risentimeno, spero sia solo dovuto a una brutta giornata...

Tengo a sottolineare che il contributo di ognuno è più che apprezzato, sebbene nel tuo caso ci sia un "velato" :lol: interesse dietro

E il fatto che un'idea, peraltro azzeccata in un contesto generico, non sia messa in pratica non deve essere preso come qualcosa di personale, perchè mai non mettere in pratica un buon consiglio? Se cerchi nel forum vedrai che in moltissimi casi i consigli dei membri, anche relativi a questioni tecniche siano stati accolti e anche con entusiasmo.

Citazione:

come faccio a farmi un backup che dura qualcosa in piu', me lo chiedo

Posso rispondere a questo dicendoti che in meno di 5 minuti è possibile fare il backup di tutti i databases su un server di AlterVista, il collo di bottiglia, per i membri, sta nel fatto che l'apache va in timeout molto prima, sebbene tale condizione permetta ugualmente a chi possiede databases medi di cavarsela ugualmente.

Inoltre il life-time è qualcosa che varia durante la giornata e soprattutto da server a server. Abbiamo a che fare con migliaia di tabelle in centinaia di databases per ogni server, con struttura e indici che variano, ogni giorno vengono eseguite migliaia di queries differenti, e proprio per questo motivo non si può prevedere un valore fisso di life-time se non un media tra tutti.
Come un database può essere sotto maggiore stress in un determinato periodo e avere un life-time inferiore, un altro, su un'altra macchina lo può essere meno, e "sopravvivere" anche a lungo.

Questo non ci autorizza a cambiare l'impostazione ad un parametro per risolvere un problema che ha praticamente incideza nulla. Se infatti fai una ricerca su questo forum, che contiene i messaggi di, credo 2 anni, e viene utilizzato per segnalare ogni piccola cosa fuori posto, vedrai che quelli che trattano di questo problema si contano sulla punta delle dita, in un forum usato per le segnalazioni di 30 - 40 mila utenti si può parlare di incidenza nulla.

Inoltre in sistema come questo (8 server, a breve 9), per ovvi motivi di "gestibilità" è strettamente necessario puntare ad un'omogeneità di configurazione, percorso ancora più obbligato dal momento che AlterVista non è un qualcosa che si utilizza solo per erogare un servizio di hosting free, ma è anche un sistema utilizzato per scopi educativi (non uso la parola ricerca perchè mi pare troppo grande), dove vengono periodicamente testate, collaudate e realizzate determinate soluzioni e applicazioni, che ovviamente richiedono un determinato humus per svilupparsi.

Concludo (finalmente) dicendo che non era mia intenzione offendere nessuno, nel caso in cui tu ti fossi realmente offeso.
Il mio rifiuto, forse ironico, alla tua proposta di assunzione non era per nulla dettato da uno scetticismo nei tuoi confronti e nei confronti delle tue capacità e conoscenze che comunque hai dimostrato di avere, ma semplicemente perchè ci sono ovvie ragioni (leggi budget) per cui non è possibile ora assumere un amministratore di sistema.

L'ironia è forse scaturita per l'ingenuità della richiesta, dettata probabilmente dalla conoscenza poco approfondita della struttura tecnica e organizzativa alla base di AlterVista, cosa peraltro più che legittima per una persona che si è iscritta pochi giorni fa.

Se ti ho offeso ti faccio le mie scuse.
31-10-2003, 18.19.46

Hai ragione, dopo una buona dormita si vedono le cose sotto un aspetto migliore ;-)
me la sono presa non per il lavoro, che sospetto non soddisferebbe le mie esigenze, dato che ho probabilmente il doppio dei tuoi anni, ma che vuol dire anche il doppio della tua esperienza , dato che faccio questo lavoro da qualche decennmio.
Sicuramente tu ti affidi alla consulenza di qualcuno di cui ti fidi, ma a capire che il mysql su AV e' solo configurato male, non ci vuole la scienza infusa, e io l'ho capito dopo pochi clic del mouse, avendo installato un package abbastanza intensivo.
Il mysql e' riconosciuto nel mondo internet come uno dei piu' performanti, pensa che i servizi diYahoo Finance sono basato su questo db. E se girasse come gira su AV l'avrebbero gia' cestinato.
A volte stando dentro il problema non si riesce piu' a vederlo nell'ottica giusta, che necessita distacco e freddezza., che per un sistemista sono le qualita' base.
Che ci siano problemi nel tuning di mysql lo si evince da molti mesaggi in proposito, e se siete arrivati alla decisione, davvero drastica, di far ripartire il db server ogni 10 minuti, immagino che siate perfettamente coscienti che e' solo una non-soluzione, e qualcosa che non quaglia c'è.
A volte arrivo a persino ad ammettere che la figura del dba un qualche senso ce l'ha ;-), anche se qui non e' un oracle. Con quello che si fanno pagare! ;)

Sono sicuro che risolverete. Al wait_timeout=30 dacci una provata.

Senza rancore
01-11-2003, 05.31.56
Gianluca

Citazione:

me la sono presa non per il lavoro, che sospetto non soddisferebbe le mie esigenze, dato che ho probabilmente il doppio dei tuoi anni, ma che vuol dire anche il doppio della tua esperienza , dato che faccio questo lavoro da qualche decennmio.

L'importante è questo, preciso che sarebbe un grande aiuto avere a disposizione un sistemista con un'esperienza del genere, ma purtroppo per ora sei fuori dalla nostra portata :)
Per intenderci AlterVista, almeno per adesso, può essere un buono sbocco lavorativo per studenti che magari vogliono fare un lavoro part-time e hanno voglia di imparare qualcosa in più, e probabilmente come dici tu stesso non soddisferebbe le tue esigenze.

Citazione:

Il mysql e' riconosciuto nel mondo internet come uno dei piu' performanti, pensa che i servizi diYahoo Finance sono basato su questo db. E se girasse come gira su AV l'avrebbero gia' cestinato.

Paragonare AlterVista a Yahoo Finance sarebbe bello ma mi sembra un po' azzardato :), non dobbiamo dimenticarci che c'è un divario (non lieve) nelle risorse a disposizione, ma anche una profondo differenza nella tipologia di servizio offerto.

Non potrà mai funzionare allo stesso modo, e non credo sia tanto un problema di configurazione, ma proprio di risorse prima di tutto in termini di macchine, come certamente saprai meglio di me l'hardware è importante per questo genere di applicazioni, per non fare poi considerazioni che forse sarebbero troppo dispersive sull'efficacia che possono avere tutte le innovazioni a livello di caching apportate alle ultime versioni quando hanno a che fare con una gamma di migliaia di query eseguite ciascuna poche volte e su un numero enorme di tabelle differenti con indici differenti piuttosto che una gamma ristretta di query che vengono invocate su poche ed enormi tabelle come può presumibilmente avvenire su un grosso portale.

Ovviamente non ci si può azzardare nell'affermare che la configurazione sia perfetta, ci mancherebbe! Se fosse perfetta non sarebbero motivati i frequenti lavori di aggiornamento, che fanno così tanto felici i membri, e tali lavori sono proprio protesi al raggiungimento di risultati via via migliori con il tempo, talvolta peggiorano anche le cose e si torna indietro, talvolta si fanno errori che i membri prontamente segnalano e proprio in base alla loro collaborazione, e quindi le segnalazioni, si sitemano.

Citazione:

Sicuramente tu ti affidi alla consulenza di qualcuno di cui ti fidi, ma a capire che il mysql su AV e' solo configurato male, non ci vuole la scienza infusa, e io l'ho capito dopo pochi clic del mouse, avendo installato un package abbastanza intensivo.

Ti posso dire che mi occupo direttamente io di questi aspetti (qualcuno potrà dire "si vede" :lol: ), su AlterVista si punta ad avere una configurazione molto "protettiva" nei confronti delle risorse, cosa molto importante per un servizio gratuito.
Questo può andare bene per le applicazioni fino a una certa complessità che possono essere forum, guestbook et similia anche per siti molto visitati.
Ovviamente se si va oltre a questo si rischia, appunto, di scontrarsi con qualcosa di non adeguato, se, per intenderci, hai intenzione di caricare qui un database che richiede più di 5 minuti per un backup probabilmente questo non è il posto adeguato, come peraltro non credo lo sia un qualsiasi altro servizio di hosting gratuito sul pianeta.

Ovviamente se tu, probabilmente dotato di un occhio allenato, hai individuato qualche possibile miglioria che possa incrementare le performances che possa però tener conto del target a cui il servizio è rivolto e quindi senza penalizzare il resto il forum è sempre qui... :) Puoi tranquillamente visualizzare la configurazione ed eventualmente suggerire modifiche alla medesima.

Tornando all'aspetto tecnico della discussione aggiungo che il mio scetticismo nell'impostare un valore di wait_timeout troppo basso era sostanzialmente giustificato dal fatto che non è possibile per i siti instaurare connessioni permanenti (e questa soluzione mi pare fosse stata da te medesimo suggerita come alternativa all'abbassamaneto del wait_timeout), infatti anche nelle ore di maggior traffico il numero di connessioni che rimangono idle è pari a 0 per i membri, differente discorso si può fare per le altre applicazioni che comunque instaurano un numero di connessioni molto limitato e perfettamente controllabile, ma hanno delle esigenze ben precise.
Tutto questo credo infatti possa spiegare come mai nonostante un wait_timeout ed un interactive_timeout così elevati il problema "too many connections" sia di incidenza praticamente nulla.

Il problema invece a cui si sta lavorando ora può essere in certi versi considerato l'opposto ed è anche questo molto comune (è una FAQ) e di banale risoluzione, ma ovviamente sulla carta :), si tratta appunto del fatidico "Mysql has gone away error", che appare sporadicamente e non può essere definito di incidenza nulla.
Si tratta comunque di una conseguenza probabilmente derivante proprio da una politica di protezione delle risorse abbastanza stretta, il tutto sta nel valutare il rapporto vantaggi/svantaggi nell'allentarla. Mi farebbe piacere avere una tua opinione anche su questo, ovviamente senza impegno :)
01-11-2003, 10.16.07

effettivamente si tratta del problema opposto
da phpinfo vedo che le connessioni persistenti sono off solo come local value, quindi c'e' una direttiva apache o in htaccess che le disabilita per, credo, i web dei membri

allungare il wait_timeout per evitare il 'server hs gone away' non ha senso per applicazioni web, che comunque muoiono e rinascono, quindi comunque rifanno una connect ogni volta. Che ci siano le connessioni persistenti o meno non importa, se non ci sono comunque viene rieseguita la connect. Un wait_timeout lungo ha senso per un lungo batch o una applicazione desktop, che tiene sempre aperta la connessione (es.: fa la connect alle 9 di mattina e la close alle 9 di sera), e lTi avevo fatto l'esempio del programma che tien scostantemente in sync due database, ma anche qui 8 ore di mancata risposta sono molte... Ai fini del web e' solo controproducente, a meno che il sito si basi tutto su un db o due, quindi un mega sito monoutente alla Yahoo, per ottimizzare la performance con allow_persistent in php.ini a questo punto. Ma non 8 ore, forse 2 o 3 minuti. Perch'e si tratta di un tempo di inattivita' oltre al quale...' le connect delle query successive fanno aprire una nuova connessione invece di riusarne una esistente
E' un po' come il KeepAliveTimeout di apache, non e' che droppa le richieste seguenti

Mysql has gone away.

da:
http://bugs.mysql.com/bug.php?id=1011
<snip>
max_allowed_packet is a server option which needs to be set in the
[mysqld] section of /etc/my.cnf, not specified to the 'mysql' client
on the command line like you're trying. But generally you're going
in the right direction - the "MySQL server has gone away" error is
caused by a query longer than the max_allowed_packet.
</snip>

Da SHOW VARIABLES vedo che il valore di max_allowed_packets e' 1!Mb.
Costui parlava addirittura di 128MB, esagerato, ma almeno 2MB ci vorrebbero, visto che tutti usano i campi blob (binary large objects)

altra causa, mi par di capire, potrebbe essere un problema di resolver, se si usa nomehost invece che localhost o IP

il parametro skip_name_resolver puo' essere quello da controllare, o magari mettere gli hostnames in /etc/hosts per evitare di contattare il dns
http://www.mysql.com/doc/en/Gone_away.html

In un sito davvero busy si e' risolto anche aumentando il parametro backlog, che tiene le richieste in coda:
http://www.faqchest.com/prgm/mysql-l...423_20998.html
ma vedo che su AV e' gia' a 50

Ma non e' che e' dovuto a query che avvengono proprio durante le (frequenti) ripartenze?

PS

Citazione:

AlterVista, almeno per adesso, può essere un buono sbocco lavorativo per studenti che magari vogliono fare un lavoro part-time e hanno voglia di imparare qualcosa in più, e probabilmente come dici tu stesso non soddisferebbe le tue esigenze.

purtroppo ho capito da un bel po' come vanno girando le cose :-( e mi sto procurando una via d'uscita con l'agrituismo e l'agricoltura biologica ;-)
http://tiki.navigare.net/tiki-browse...p?galleryId=17
01-11-2003, 19.06.51
Gianluca

Citazione:

Da SHOW VARIABLES vedo che il valore di max_allowed_packets e' 1!Mb.
Costui parlava addirittura di 128MB, esagerato, ma almeno 2MB ci vorrebbero, visto che tutti usano i campi blob (binary large objects)

Questa possibilità era stata presa in considerazione, c'erano state alcune segnalazioni in relazione al ripristino di alcuni dumps costituiti, per risparmiare spazio, praticamente di una singola query INSERT (lunghissima) e in questo caso di poteva ovviare spezzando le insert troppo lunghe in una serie di queries più piccole.

Ma la ragione principare che ci aveva spinto a cercare oltre è il fatto che l'errore si presentasse anche in presenza di queries molto semplici, come poteva essere la lettura di un post su un forum piuttosto che la modifica di un messaggio in un guestbook.

Comunque nn sono mai state fatte delle prove significative con un valore più alto, quindi sarà certamente testato un valore di almeno 2 MB, non si può mai escludere nulla.

Citazione:

altra causa, mi par di capire, potrebbe essere un problema di resolver, se si usa nomehost invece che localhost o IP

il parametro skip_name_resolver puo' essere quello da controllare, o magari mettere gli hostnames in /etc/hosts per evitare di contattare il dns
http://www.mysql.com/doc/en/Gone_away.html

Purtroppo anche questa eventualità era stata presa in esame, infatti è un parametro abilitato nella configurazione, anche perchè le connessioni ai database avvengono solo in locale.

Citazione:

In un sito davvero busy si e' risolto anche aumentando il parametro backlog, che tiene le richieste in coda:
http://www.faqchest.com/prgm/mysql-l...423_20998.html
ma vedo che su AV e' gia' a 50

Questa possibile soluzione non era stata tentata, anche se, come tu stesso hai notato il valore impostato è già alto.

Si era anche ipotizzato il fatto che mysql non avesse sufficienti descrittori a disposizione, ipotesi scartata quasi subito anche perchè si avrebbe in questo caso un errore direttamente a livello di connessione.

Citazione:

Ma non e' che e' dovuto a query che avvengono proprio durante le (frequenti) ripartenze?

Temo sia proprio questa la causa, le frequenti ripartenze che, grazie a Dio si manifestano non su tutte le macchine ma tipicamente in quelle dove il database è più sotto stress.
Purtroppo è ciò che sta alla base di questo tempo di vita limitato che è difficile da individuare.

Il fatto che vengano invocate migliaia di queries differenti, su databases, tabelle e indici più disparati, magari ognuna una sola volta al giorno, rende statisticamente molto più probabile eseguire una query che induce al crash.

Rovesciando quindi il punto di vista si può pensare che un errore di questo tipo si possa manifestare proprio invocando una query "cattiva". E in questo caso penserei anche ad un concorso di colpa tra applicazioni e db stesso.
A rafforzare questa mia tesi è il fatto che quando si utilizzava la versione 3, a cui per motivi tecnici non si può tornare, questo errore era rarissimo, ad incidenza praticamente nulla, dopo l'upgrade alla versione 4 ha iniziato a manifestarsi.

Questo è a grandi linee un riassunto delle considerazioni maturate e del lavoro di semplice test che si è fatto fino ad ora per risolvere il problema.
01-11-2003, 20.30.49

Ah! quindi le ripartenze non sono da cron, ma da un qualche tool di monitoraggio. Sono rimasto indietro sul mysql... Quale per curiosita? E su quali parametri decide la ripartenza?
PS O forse crasha tutto il server e c'e' un watchdog che lo fa ripartire? C'e' un adagio sempre valido e non tanto stupido: when it crashes there is a bug :-(

Bisognerebe avere a disposizione il show full processlist per analizzare bene il problema, se il problema 'server has gone' e' dovuto alle ripartenze, e le ripartenze sono dovute a 'too many connections', allora la causa e' quest'ultima, altrimenti...

'server has gone' e' un problema che riguarda un singolo child di mysql, che muore (ma forse perche' e' stato killato insieme a tutti gli altri per una ripsrtenza). 'too many connections' e' un problema di stallo generale, tutto il servizio smette di ridpondere.

Una query cattiva puo' essere una che inserisce una immagine in un blob... Alzare il max_allowed_packets e' la soluzione prima da provare

Forse confrontando il setup in uso sulla versione 3 e quello attuale si puo' capire qualcosa....
03-11-2003, 19.46.14
Gianluca

Citazione:

Ah! quindi le ripartenze non sono da cron, ma da un qualche tool di monitoraggio. Sono rimasto indietro sul mysql... Quale per curiosita? E su quali parametri decide la ripartenza?
PS O forse crasha tutto il server e c'e' un watchdog che lo fa ripartire? C'e' un adagio sempre valido e non tanto stupido: when it crashes there is a bug

Non viene fatto il riavvio sistematico del database ogni x secondi o minuti via cron, io con "crash" non intendevo il crash completo del server, ma il crash dei singoli figli.
Di fatto questo crash non ha conseguenze globali ma genera, come suppongo, il fatidico errore, ed eventualmente una corruzione della tabella se in update.
Più o meno frequentemente tutti i figli muoiono, per intenderci, nell'error log:

Citazione:

Number of processes running now: 0
031103 16:34:01 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.16-standard-log' socket: '/var/lib/mysql/mysql.sock' port: 3306

Number of processes running now: 0
031103 18:09:01 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.16-standard-log' socket: '/var/lib/mysql/mysql.sock' port: 3306

E la distanza tra i due restart, evento totalmente autonomo e non forzato da alcunchè, può variare molto, a volte si arriva anche a giorni come anche a minuti.

Il crash completo del database è sì un evento che si verifica, ma è relativamente raro.
Nel caso peggiore se ne verificano 3 o 4 la settimana, mediamente 1 ogni 15 giorni, su alcuni server addirittura 1 ogni 2 mesi o mai per alcuni periodi di tempo.
Esiste comunque un sistema di monitoraggio (sviluppato in casa) che tiene d'occhio il database e, in caso di crash completo o comunque stallo lo riavvia autonomamente entro 4 minuti

Citazione:

Bisognerebe avere a disposizione il show full processlist per analizzare bene il problema, se il problema 'server has gone' e' dovuto alle ripartenze, e le ripartenze sono dovute a 'too many connections', allora la causa e' quest'ultima, altrimenti...

'server has gone' e' un problema che riguarda un singolo child di mysql, che muore (ma forse perche' e' stato killato insieme a tutti gli altri per una ripsrtenza). 'too many connections' e' un problema di stallo generale, tutto il servizio smette di ridpondere.

Proprio in base a quello che ho scritto sopra il problema, amio parere, non riguarda tanto uno stallo generale ma sembrerebbe relativo al sigolo processo, proprio perchè se di stallo generale si trattasse il sistema di monitoraggio riavvierebbe il database molto più spesso, inoltre quando si ha un riavvio viene anche loggato l'eventuale messaggio d'errore restituito da una query di prova, ed esso è in genere il classico "Can't connect to local MySQL server through socket 'xxx' (2)".

Citazione:

Una query cattiva puo' essere una che inserisce una immagine in un blob... Alzare il max_allowed_packets e' la soluzione prima da provare

L'inserimento di immagini o di dati binari nel database può essere senz'altro una possibile causa, sebbene questo genere di appicazioni, siano piuttosto di "nicchia" su AlterVista, senz'altro comunque sarà provata anche questa possibilità.
Sottolineo però che tale errore si manifesta anche con query poco impegnative su basi di dati relativamente piccole.

Citazione:

Forse confrontando il setup in uso sulla versione 3 e quello attuale si puo' capire qualcosa....

Purtroppo il setup è proprio ricalcato su quello vecchio, sono state aggiunte alcune impostazioni per abilitare la query cache, non disponibile nelle vecchie versioni, skip-name-resolve e adeguati parametri in base alla crescente disponibilità di memoria, nulla di più :?
04-11-2003, 02.59.31

scopro che c'e' anche un undocumented
loose-max_allowed_packets=1G
chisaa' chi ha bisogno di 1G
http://bugs.mysql.com/bug.php?id=1012
Comunque lo alzerei
Monty Widenius specificatamente lo consiglia poer server 'has gone'
http://bugs.mysql.com/bug.php?id=1011
<snip>
This problem is already documented in the manual section
'MySQL server has gone away Error':
-----
You can also get these errors if you send a query to the server that is
incorrect or too large. If mysqld gets a packet that is too large.
or out of order, it assumes that something has gone wrong with the client and
closes the connection.
-----
We fixed this problem in 4.0 for not compressed packets but for
compressed packets it's VERY hard to fix it without having to allocate
a buffer bigger than max_allowed_packet
</snip>

si tratta di un valore dinamico, allocato solo alla bisogna, ed effettivamente secondo il manuale 16M non sono astrusi
http://www.mysql.com/doc/en/Packet_too_large.html
<snip>
It's safe to increase this variable as memory is only allocated when needed; this variable is more a precaution to catch wrong packets between the client/server and also to ensure that you don't accidentally use big packets so that you run out of memory.
...
For example, if you are expecting to store the full length of a MEDIUMBLOB into a table, you'll need to start the server with the set-variable=max_allowed_packet=16M option.
</snip>

L'applicaz che ho installato ad esempio, tiki, puo' usare i blob o il filesystem per storare le immagini. Forse per eludere il disk quota in /var/lib/mysql ;-) ?
Mi chiedo se una fa una select di tutti i thumbnail di una galleria di immagini.
07-11-2003, 20.22.39
Gianluca

Non mi sono dimenticato di questo post :)

Rispondo solo ora in quanto volevo prima avere in mano qualcosa di concreto da apportare alla discussione.

Per quanto riguarda il problema dell'eventuale malconfigurazione di max_allowed_packet la questione sembra essere stata in parte risolta, intendo dire dal punto di vista della diagnostica.

Si considerava infatti il nostro errore, intendo dire "mysql has gone away..." come qualcosa provocato da un pacchetto "malformato" o eccessivo in grandezza, cosa peraltro da sempre riportata sulla documentazione, e invece, a quanto pare, non è più così.
Dalle ultime versioni (il suggerimento dell'utente è stato ascoltato) è infatti stato introdotto un nuovo codice d'errore, specifico per la seconda alternativa.

Per quanto riguarda il resto, è stata presa in seria considerazione la possibilità di adottare una soluzione più elegante per pemettere la coesistenza di applicazioni di diverso genere, con esigenze differenti, utilizzando database servers differenti, in questo modo si avrà auspicabilmente una maggior efficienza (è tutto da provare) potendo anche plasmare le varie configurazioni su esigenze più specifiche, e quindi si potranno abilitare le connessioni persistenti al database per i membri potendo lavorare con maggiore libertà su parametri come il wait_timeout et similia.

Citazione:

L'applicaz che ho installato ad esempio, tiki, puo' usare i blob o il filesystem per storare le immagini. Forse per eludere il disk quota in /var/lib/mysql ?
Mi chiedo se una fa una select di tutti i thumbnail di una galleria di immagini.

Credo che il motivo per cui si possa utilizzare il database per le immagini sia proprio quello che hai scritto, a parte ovviamente una forma di attaccamento morboso al database..., comunque lo spazio che i membri occupano in database va a sottrarsi allo spazio che hanno a disposizione nell'account, quindi fare una cosa del genere, a mio parere, non porterebbe che svantaggi, almeno qui, essendoci configurazioni piuttosto protettive in termini di risorse.