problemi PermGen con ascensore e Jetty

StackOverflow https://stackoverflow.com/questions/1451648

Domanda

sto sviluppando sulla piattaforma di sollevamento standard (Maven e pontile). Sono più volte (una volta ogni due giorni) ottenendo in questo modo: 

Exception in thread "7048009@qtp-3179125-12" java.lang.OutOfMemoryError: PermGen space
2009-09-15 19:41:38.629::WARN:  handle failed
java.lang.OutOfMemoryError: PermGen space

Questo è nel mio ambiente dev. Non è un problema, perché io possa mantenere il riavvio del server. In distribuzione non sto avendo questi problemi, quindi non è un problema reale. Sono solo curioso.

Non so troppo di JVM. Penso di essere corretto nel pensare che la memoria di generazione permanente è per cose come le classi e le stringhe internati? Quello che ricordo è un po 'confuso con il modello di memoria .NET ...

Qual è il motivo per cui questo sta accadendo? Sono i valori di default solo follemente basso? E 'a che fare con tutti gli oggetti ausiliari che Scala deve creare per oggetti funzione e simili cose FP? Ogni volta che ricomincio Pontile con codice appena scritto (ogni pochi minuti) Immagino che ri-carica le classi ecc Ma anche così, posso' essere che molti può? E non dovrebbe la JVM essere in grado di affrontare un gran numero di classi?

Saluti

Joe

È stato utile?

Soluzione

questo post :

  

Questa eccezione si è verificata per una semplice ragione:
  la permgenspace è dove le proprietà di classe, come metodi, campi, annotazioni e anche variabili statiche, ecc, sono memorizzati nella Java VM, ma questo spazio ha la particolarità di non essere puliti dal garbage collector .   Così, se il webapp utilizza o crea un sacco di classi (sto pensando generazioni dinamiche delle classi), è probabile che si sono incontrati questo problema.   Ecco alcune soluzioni che mi hanno aiutato a sbarazzarsi di questa eccezione:

  • -XX:+CMSClassUnloadingEnabled: questa impostazione consente la raccolta dei rifiuti nel permgenspace
  • -XX:+CMSPermGenSweepingEnabled: permette il garbage collector per rimuovere anche le classi dalla memoria
  • -XX:PermSize=64M -XX:MaxPermSize=128M: solleva la quantità di memoria allocata al permgenspace

Può essere questo potrebbe aiutare.

Modifica luglio 2012 (quasi 3 anni più tardi):

Ondra Žižka commenti (e ho aggiornato la risposta di cui sopra):

  

JVM 1.6.0_27 dice: Si prega di utilizzare:

  • CMSClassUnloadingEnabled (Sia classe scarico attivo con CMS GC)
  • al posto di CMSPermGenSweepingEnabled in futuro

Vedere la piena Hotspot JVM Opzioni -. Il riferimento completo per mroe

Altri suggerimenti

Se vedete questo durante l'esecuzione mvn jetty:run, impostare il MAVEN_OPTS.

Per Linux: 

export MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M"
mvn jetty:run

Per Windows: 

set "MAVEN_OPTS=-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M"
mvn jetty:run

Dovrebbe andare bene ora. In caso contrario, aumentare -XX:MaxPermSize.

Si può anche mettere questi in modo permanente al vostro ambiente.

Questo è a causa del ricarico dei corsi come lei ha suggerito. Se si utilizza un sacco di librerie, ecc somma delle classi sarà rapidamente crescere per ogni riavvio. Prova il monitoraggio l'istanza molo con VisualVM per avere una panoramica del consumo di memoria quando ricarico.

La mailing list ( http://groups.google.com/group/liftweb/) è il forum ufficiale di supporto per sollevamento, e dove sarete in grado di ottenere una risposta migliore. Non conosco i particolari della configurazione di dev (non si va troppo nei dettagli), ma suppongo che stai ricaricando il tuo guerra in Jetty senza in realtà riavviarlo. Ascensore non esegue la generazione dinamica di classe (come suggerito da VonC sopra), ma Scala compila ogni chiusura di una classe separata. Se stai aggiungendo e rimuovendo le chiusure al codice nel corso di diversi giorni, è possibile che anche molte classi vengono caricati e mai scaricato e occupare spazio perm. Io suggerirei di attivare le opzioni di opzioni JVM menzionati da VonC sopra e vedere se aiutano.

La generazione permanente è dove la JVM mette cose che non sarà probabilmente (spazzatura) raccolti come classloader personalizzati.

A seconda di cosa si sta distribuendo, l'impostazione gen perm può essere bassa. Alcune applicazioni e / o contenitori di combinazione contengono alcune perdite di memoria, in modo che quando un app ottiene undeployed a volte un po 'di roba come caricatori di classe non sono raccolti, con conseguente riempimento del Perm Spazio quindi generare l'errore si stanno avendo.

Purtroppo, attualmente la migliore opzione in questo caso è al massimo lo spazio permanente con il seguente bandierina JVM (esempio per 192m perm dimensioni): 

-XX:MaxPermSize=192M (or 256M)

L'altra opzione è quella di fare in modo che sia il contenitore o il quadro non perdita di memoria.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top