2015-10-19 23 views
5

descrizione ProblemaMetaspace questioni concumption memoria di Java 8 applicazioni implementate su WIlfly 8.2.1

ho notato che ogni distribuzione di uno della nostra applicazione Java8 su wildfly 8.2.1 utilizza circa 30-40 MB di memoria da Metaspace piscina. Va bene, ma il fatto è che quando sto ridistribuendo la stessa app l'utilizzo della memoria di Metaspace viene aumentato dagli stessi 30-40 MB mentre la vecchia memoria già allocata non viene rilasciata.

Non me ne accorgo nemmeno, ma il fatto è che abbiamo 20 applicazioni e di volta in volta ho bisogno di ridistribuirle fino a 10 allo stesso tempo. Ciò a sua volta produce un'immagine spaventosa.

enter image description here Fondamentalmente ciò che viene mostrato sono le 2 ridistribuzioni di ~ 10 applicazioni.

Non sono sicuro del motivo per cui GC non può rilasciare la memoria allocata alle vecchie classi. Questo server ha una memoria fisica totale da 16 GB, quindi posso ridistribuire tutte le app fino a 20-40 volte e basta. Il server delle app raggiungerà il limite e smetterà di rispondere a qualsiasi comando.

Quindi sarei molto grato se qualcuno potesse aiutarmi a capire quale sia il problema effettivo potrebbe essere:

  1. Si tratta di un problema di Java8? (jdk 1.8.0_40-b26)
  2. È un problema di Wildfly 8.2.1?
  3. O è la risposta più semplice possibile che la causa è la mia base di codice? Se è così, potresti per favore guidarmi quale potrebbe essere la vera ragione?

Alcuni dettagli relativi alla mia base di codice

1) Assieme wildfly io uso 2 server standalone HornetQ, ogni applicazione utilizza ~ 5 canali con almeno 5 utenti simultanei su ciascuno. Il che a sua volta comporta almeno 25 thread per ogni app e almeno 25 * 20 = 500 thread in totale.

2) Per tutte le operazioni JMS di basso livello, utilizzo Spring JMS.

risposta

1

WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" si verifica e verrà risolto. Fare riferimento a seguire Agile Consiglio di wildfly

https://issues.jboss.org/browse/WFLY-6173

+0

Benvenuto in Stack Overflow! Un link a una potenziale soluzione è sempre il benvenuto, ma per favore [aggiungi contesto intorno al link] (http://meta.stackoverflow.com/a/8259/169503) così i tuoi colleghi avranno un'idea di cosa sia e perché sia Là. Citare sempre la parte più rilevante di un link importante, nel caso in cui il sito target non sia raggiungibile o sia permanentemente offline. Considera che essere appena più di un link a un sito esterno è una possibile ragione per [Perché e come vengono eliminate alcune risposte?] (Http://stackoverflow.com/help/deleted-answers). – ddb

+0

Il contesto è lì. È un bug nell'applicazione e verrà risolto. Dato che questo errore è comune e questa pagina è uno dei principali hit di Google per il problema, eliminando questa risposta si causerebbe più danni alla comunità che buoni. – tggm

1

Per determinare empiricamente dove e se si ha una perdita (potrebbe non esserci una perdita - potrebbero semplicemente essere classi legittime caricate durante le distribuzioni per motivi legittimi) si potrebbe provare taking a heap dump al momento giusto (cioè prima o dopo il si verifica un aumento del metaspazio). Quindi, prendi un'altra discarica di heap. Diff i due dump di heap utilizzando uno strumento come MAT o Yourkit. Il diff tra i due ti dirà quali classi vengono caricate.

Le perdite nel metaspace sono piuttosto rare perché hai solo così tante classi da caricare ma potrebbe anche essere qualcosa di piuttosto esotico in gioco.

Fammi sapere cosa trovi e buona caccia! Questi sono divertenti. :-)

+0

ho analizzato entrambe le discariche mucchio (prima e dopo ridistribuendo ~ 5 artifcats) e ho notato qualcosa suspecious ancor prima di calcolare la differenza: 1.prima http://snag.gy/JGZdf.jpg 2. dopo http://snag.gy/VqFiN.jpg Ed ecco la differenza: http://snag.gy/xfDeV.jpg Vedo quel salmerino [] array sta crescendo molto. (sembra il contenuto di String) Ecco il contenuto di org.jboss ... JavaZipFileSystem class loader: http://snag.gy/bbYq7.jpg Quindi ho l'impressione che WildFly carichi semplicemente tutti gli artefatti nel memoria e non li rilascia anche dopo la ridistribuzione. Potrebbe essere vero e va bene? – Andrew

+0

Fantastico! Ecco alcuni suggerimenti: 1. Desiderate alcuni dump tra una distribuzione e l'altra per trovare un modello di utilizzo di mem monotonicamente crescente, filtrando gli oggetti casuali. 2. Cercare di trovare i dati all'interno degli oggetti che si sospetta causino la perdita (cioè i valori nei nodi); quello può condurre la tua scientifica. 3. Assicuratevi di investigare sul meta spazio in cui si sospetta che la perdita sia, e non sull'heap. 4. Sì, i tipi char [] e altri primitivi oscillano molto. È più facile trovare la perdita a livelli più alti. 5. Sì, WildFly potrebbe facilmente caricare le classi e non rilasciarle. Lo scaricamento di una classe è facoltativo per una JVM. – entpnerd

+0

Hai trovato qualche soluzione a questo? Sto riscontrando lo stesso problema – Deibys