Grazie a tutti per le risposte :) sinora ho visto JProfiler e VisualVM come tools: JProfiler è superiore, ma VisualVM è free (almeno mi pare).
In ogni caso in effetti potrebbe non essere un memory leak come evidenziato sopra ma semplicemente la memoria di java che cresce e il container viene killato perchè supera la memoria del docker, quindi per prima cosa sto indagando in questo senso, forse basta solo dare dei setting oppurtuni alla JVM e al docker. Ciao On Fri, Jun 7, 2019 at 1:37 AM Uberto Barbini [email protected] [it-torino-java-jug] <[email protected]> wrote: > > > Me lo segno da vedere! Jack e' un grande.. > > Personalmente mi capita una due volte l'anno in media di investigare veri > o presunti memory leaks e conoscendo la code base di solito ci vuole > qualche ora per capire. > > Ho fatto quest'anno il seminario con Kirk Pepperdine che per mestiere fa > questo su code bases che non conosce e spesso scritte malissimo. > A lui bastano 5 minuti in genere per capire il problema ma poi serve un > meeting di 5 ore col cliente per spiegarglielo. :) > Effettivamente ci sono un mucchio di tool potentissimi nel env java che > non conoscevo. > > Uberto > > > > On Thu, 6 Jun 2019 at 22:11, Marco Bartolini [email protected] > [it-torino-java-jug] <[email protected]> wrote: > >> >> >> ho sempre usato un mix di tool, ma al DevoXX quest anno hanno presentato >> per bene un debug >> >> https://www.youtube..com/watch?v=JoQN4xoXY5Y >> <https://www..youtube.com/watch?v=JoQN4xoXY5Y> >> >> On Thu, 6 Jun 2019 at 00:18, Uberto Barbini [email protected] >> <[email protected]> [it-torino-java-jug] < >> [email protected]> wrote: >> >>> >>> >>> Un altro paio di considerazioni: >>> In Java quelli che chiamiamo memory leaks in realta' di solito sono solo >>> allocazioni di memoria di cui ci siamo "dimenticati". >>> Per esempio thread orfani che restano appesi (con tutti i loro oggetti) >>> o cache che non vengono svuotate regolarmente. >>> Le eccezioni sono bugs nella JVM (ogni tanto ce n'e' qualcuno) e >>> allocazioni JNI. >>> Un altro caso che puo' dare problemi e' una super allocazione di memoria >>> di picco che sfora l'heap prima che il GC possa ripulire. >>> Pero' non mi sembra il caso qui. >>> >>> Un altro tool utile per fare investigazioni sulla memoria e' MAT di >>> Eclipse, e' indipendente dall'IDE e se mi ricordo bene ha anche un bottone >>> "scopri memory leaks" che fa un po' di euristiche niente male. >>> https://www.eclipse.org/mat/ >>> >>> Uberto >>> >>> On Wed, 5 Jun 2019 at 21:06, Uberto Barbini <[email protected]> >>> wrote: >>> >>>> Per trovare il memory leak in fretta ti basta fare un memory dump con >>>> l'applicazione che gira da un po' e poi guardarci con visualvm. >>>> I casi più semplici li trovi cercando le classi tue con più istanze. >>>> >>>> Metodi più sofisticati richiedono analizzare i log del gc, ma di solito >>>> lo vedi da visualvm >>>> >>>> Uberto >>>> >>>> On Wed, 5 Jun 2019, 15:36 Salvatore Spoto [email protected] >>>> [it-torino-java-jug], <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> Ciao a tutti, >>>>> avrei la necessità di trovare dei memory leak in un'applicazione java. >>>>> >>>>> Il sintomo è abbastanza banale: la memoria cresce costantemente nel >>>>> tempo, senza essere mai liberata, e questo porta il processo ad essere >>>>> ucciso quando raggiunge i limiti di memoria pre determinati del container >>>>> (l'applicazione gira in un docker). >>>>> >>>>> Qualcuno saprebbe consigliari dei profiler, tool o best practice per >>>>> eseguire questo lavoro ? >>>>> >>>>> Ho visto che vi sono JProfile e YourKit, purtroppo sono commerciali, >>>>> ma sembrano ottimi. Anche lo stesso Java Mission Control credo che >>>>> richieda >>>>> una licenza per essere usato in ambienti di produzione. Forse di >>>>> quest'ultimo vi è una versione open source sulla jdk 11, ma io sto >>>>> lavorando ancora sulla 7 :_/. >>>>> >>>>> Grazie delle dritte..... >>>>> >>>>> Ciao, >>>>> Salvatore >>>>> >>>>> >
