Ho una perdita di memoria in due app nel server Tomcat 6.0.35 che è apparso "dal nulla". Un'app è Solr e l'altra è il nostro software. Spero che qualcuno l'abbia già visto come mi è successo nelle ultime settimane e devo continuare a riavviare Tomcat in un ambiente di produzione.Perdita di memoria in più app
E 'apparso sul nostro server originale nonostante il fatto che nessuno del codice relativo alle operazioni di connessione thread o DB sia stato toccato. Dato che il vecchio server su cui è stata eseguita questa app doveva essere ritirato, ho migrato il sito su un nuovo server e un ambiente più "pulito" con l'idea che eliminasse qualsiasi materiale legacy. Ma continua ad accadere.
Poco prima di Tomcat spegne il registro catalina.out è pieno di errori come:
2012-04-25 21: 46: 00.300 [principale] ERRORE org.apache.catalina.loader.WebappClassLoader- L'applicazione web [/ AppName] sembra aver avviato un thread chiamato [MultiThreadedHttpConnectionManager cleanup] ma non è riuscito a fermarlo. È molto probabile che questo crei una perdita di memoria.
2012-04-25 21: 46: 00,339 [principale] ERRORE org.apache.catalina.loader.WebappClassLoader- L'applicazione Web [/ AppName] sembra aver avviato una discussione denominata [com.mchan ge.v2 .async.ThreadPoolAsynchronousRunner $ PoolThread- # 2] ma non è riuscito a fermarlo. È molto probabile che questo crei una perdita di memoria.
2012-04-25 21: 46: 00,470 [principale] ERRORE org.apache.catalina.loader.WebappClassLoader- L'applicazione Web [/ NomeApp] sta ancora elaborando una richiesta che non ha ancora a scadenza ish. È molto probabile che questo crei una perdita di memoria. È possibile controllare il tempo concesso per il completamento delle richieste utilizzando l'attributo unloadDelay dell'implementazione standard di Conte xt.
Durante che la migrazione siamo passati da Solr 1.4-> 3.6 Solr, nel tentativo di risolvere il problema. Quando gli errori sopra riportati iniziano a riempire il log, l'errore Solr di seguito segue immediatamente dopo ripetuti 10-15 volte e poi Tomcat smette di funzionare e devo eseguire shutdown e startup per farlo rispondere.
2012-04-25 21: 46: 00.527 [principale] ERRORE org.apache.catalina.loader.WebappClassLoader- L'applicazione web [/ solr] creato un ThreadLocal con chiave di tipo [org.a pache .solr.schema.DateField.ThreadLocalDateFormat] (value [[email protected]]) e un valore di tipo [org.apache.solr. schema.DateField.ISO8601CanonicalDateFormat] (valore [org.apache.solr.schema.DateField$ISO8601CanonicalDat[email protected]]) ma non è riuscito a rimuoverlo quando il web ha interrotto una richiesta . È molto probabile che questo crei una perdita di memoria.
La mia ricerca ha sollevato molti suggerimenti sulla modifica del codice che gestisce i thread per assicurarsi che eliminino le connessioni in pool DB ecc. Ma questo codice non è stato modificato in circa 12 mesi. Anche l'applicazione Solr sta andando in crash e questa è la terza parte quindi penso che questo sia ambientale (jar conflict, versioning, config fat fingered?)
La mia ultima modifica è stata l'aggiornamento del connettore mysql per java al più recente come una perdita di memoria esistevano bug attorno al pool nelle versioni precedenti ma il server si è appena bloccato di nuovo solo poche ore dopo.
Una cosa che ho notato è che sto visualizzando migliaia di sessioni nel web manager Tomcat ma potrebbe essere una falsa pista.
Se qualcuno ha visto questo aiuto è molto apprezzato.
[Edit]
Credo di avere trovato la fonte del problema. Dopotutto non era una perdita di memoria. Ho rilevato un'applicazione da un altro team di sviluppo che utilizza c3p0 per il pool di database tramite Hibernate. c3p0 ha un bug/funzionalità che se non si rilasciano connessioni DB c3p0 può andare in uno stato di attesa una volta che tutte le connessioni (tramite MaxPoolSize: valore predefinito è 15) vengono utilizzate. Attenderà indefinitamente per rendere disponibile una connessione. Da qui il mio stallo.
Ho tolto il MaxPoolSize prima da 25-> 100 e la mia applicazione ha funzionato per diversi giorni senza blocco e poi da 100-> 1000 ed è rimasta stabile da allora (oltre 2 settimane).
Questa non è la soluzione completa come ho bisogno di scoprire perché è a corto di connessioni in pool in modo da impostare anche unreturnedConnectionTimeout di c3p0 a 4 ore, che impone un limite di tempo 4 ore su tutti i collegamenti, indipendentemente dal fatto che siano attive o no . Se è una connessione attiva, la chiuderà e riaprirà di nuovo.
Non carino e c3p0 non lo consiglio ma mi dà un po 'di respiro per scoprire la fonte del problema.
Nota: quando si utilizza c3p0 con Hibernate, le impostazioni sono memorizzate nel file persistence.xml ma non tutte le impostazioni possono essere inserite. Alcune impostazioni (ad es unreturnedConnectionTimeout) devono andare in c3p0.properties
Provare ad osservare il tomcat jvm con jvisualvm nel jdk. –
Grazie Thorbjørn. Ho lasciato correre jvisualvm durante la notte e nulla si è distinto. Il GC stava accadendo come previsto, un sacco di spazio nell'heap (circa il 30% in uso, il 50% massimo utilizzato), PermGen era buono (circa il 30% utilizzato). Non avevo JMX configurato per l'accesso remoto, quindi non ho ottenuto un'immagine completa. Ho chiuso jvisualvm per andare al lavoro e ho ricevuto una chiamata 30 minuti dopo per dire che il sito stava aprendo la prima pagina, ma qualsiasi accesso al database (login/ricerca) si era fermato di nuovo. Molto strano. –
sembra esserci un problema simile aperto su solr https://issues.apache.org/jira/browse/SOLR-2357 non ancora risolto – JoseK