Prima capiamo le proprietà di mysql.
interactive_timeout
: tempo interattivo per sessioni di shell mysql in secondi come mysqldump o mysql strumenti di comando. le connessioni sono in stato di sospensione. Il più delle volte questo è impostato su un valore più alto perché non vuoi che venga disconnessa mentre stai facendo qualcosa su mysql cli.
wait_timeout
: la quantità di secondi durante l'inattività che MySQL attenderà prima di chiuderà una connessione su una connessione non interattiva in secondi. esempio: connesso da java. le connessioni sono in stato di sospensione.
Ora cerchiamo di capire le proprietà C3PO ed è relazione con i puntelli DB (Sono copia solo andando dalla tua domanda)
maxIdleTime
:. (Default: 0) secondi una connessione può rimanere in pool, ma inutilizzato prima di essere scartato. Zero significa che le connessioni inattive non scadono mai .
Questo si riferisce a quanto tempo un oggetto di connessione può essere utilizzabile e sarà disponibile in piscina. Una volta scaduto il timeout, c3po lo distruggerà o lo riciclerà.
Ora il problema si presenta quando si dispone di maxIdleTime
superiore a wait_timeout
. diciamo se il mxIdleTime : 50
sec e wait_timeout : 40 s
quindi c'è un chanse che si otterrà Connection time out exception: Broken Pipe
se si tenta di fare qualsiasi operazione negli ultimi 10 secondi. Quindi maxIdelTime
dovrebbe sempre essere inferiore a wait_timeout
.
Invece di maxIdleTime è possibile le seguenti proprietà.
idleConnectionTestPeriod
imposta un limite a quanto tempo una connessione sarà rimanere inattivo prima testarlo. Senza preferredTestQuery
, il valore predefinito è DatabaseMetaData.getTables()
- che è indipendente dal database e sebbene una chiamata relativamente costosa, è probabilmente valida per un database relativamente piccolo . Se siete paranoici su prestazioni utilizzare una query specifica al database (i.e. preferredTestQuery="SELECT 1")
maxIdleTimeExcessConnections
riporterà il connectionCount di nuovo verso il basso per minPoolSize dopo un picco di attività.
Si prega di notare che qualsiasi della proprietà piscina (ad es. maxIdleTime
) colpisce solo per collegamento che sono in piscina cioè se Hibernate ha acquisito una connessione e la mantiene al minimo per oltre MaxIdleTime e poi cerca di fare qualsiasi operazione Otterrai "Broken Pipe"
È buona cosa avere wait_timeout
inferiore su mysql ma non è sempre giusto quando hai un'applicazione già compilata. Prima di ridurlo devi assicurarti che nella tua applicazione non stai mantenendo la connessione aperta per più di wait_time
uscita.
Inoltre, è necessario considerare che l'acquisizione di una connessione è un'attività costosa e se il tempo di attesa è troppo basso, supera l'intero scopo di disporre di un pool di connessioni, poiché tenterà spesso di acquisire connessioni.
Ciò è particolarmente importante quando non si esegue la gestione della connessione manualmente, ad esempio quando si utilizza l'API transnazionale Spring. Spring avvia la transazione quando si immette un metodo annotato @Transaction
in modo che acquisisca una connessione dal pool. Se stai facendo una chiamata al servizio web o stai leggendo un file che richiederà più tempo di wait_time, otterrai un'eccezione.
Ho affrontato questo problema una volta.
In uno dei miei progetti ho avuto un cron che avrebbe effettuato l'elaborazione degli ordini per i clienti. Per renderlo più veloce ho usato l'elaborazione in batch. Ora, una volta recuperato un gruppo di clienti, eseguo alcune elaborazioni (senza chiamate DB). Quando provo a salvare tutti gli ordini che ho usato per ottenere l'eccezione del tubo rotto. Il problema era che il mio wait_timeout era di 1 minuto e che l'elaborazione degli ordini richiedeva più tempo. Quindi abbiamo dovuto aumentarlo a 2 minuti. Avrei potuto ridurre le dimensioni del batch, ma questo rallentava l'elaborazione complessiva.
Le connessioni in modalità sonno sono molto probabilmente il connessioni inattive che si trovano nella vostra piscina. Non dovrebbero essere chiusi troppo velocemente perché avere la piscina per ricrearli alla prossima richiesta è costoso. Perché il tuo DBA suggerisce che il wait_timeout sia impostato su 30 secondi? – flup
@flup, perché durante il test del carico ho osservato che 'mostra la lista completa dei processi 'mostrandomi il' numero di connessioni in DB = maxPoolSize' e sto ottenendo continuamente l'eccezione 'Connessioni non potendo essere acquisita dal database sottostante!'. Ho postato questa domanda Per saperne di più e uno http://stackoverflow.com/questions/24451317/why-sleep-mode-coonections-are-not-reused-by-c3p0 – Amogh