---

Hej

Jeg har et setup, hvor jeg forsøger at drive en en Java
webapplikation, som jeg også selv udvikler på. Jeg forsøger at drive
det hele på et par 32 bit servere.

Jeg bruger Suns Java6 under Linux, og Apache Tomcat 6 som servlet
container.

Jeg har haft et hav af problemer med JVM'en, særligt garbage
collectoren har fået min JVM til at crashe et utal af gange de sidste
par år. Det lader ikke til at det er noget Sun arbejder så hårdt på at
fikse, selv om jeg ofte oplever at JVM'en crasher flere gange om ugen.

Men nu, efter jeg skiftede til Java6 er jeg også begyndt at få fejl
fordi JVM'en løber tør for native heap space selv om den bruger over
en GB til native heap. Det giver OutOfMemory-exceptions, og nogle
gange crash.

Sun har taget imod en bug report:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568433

Det er jo en god start, de plejer ellers at afvise mine bugreports
fordi jeg har svært ved at lave kode-eksempler der kan genskabe de
crashes jeg oplever i forbindelse med garbage collectoren.

Er jeg virkelig den eneste der forsøger at drifte Java applikationer
der oplever den slags? Jeg synes ikke at Google er fyldt med folk der,
som jeg har problemer med ustabile JVM'er.

Hvordan gør I andre for at holde jeres Java-baserede webapplikationer
i luften? Er I alle skiftet til 64 bit hardware?

Xpost mellem d.e.programmering.java og d.e.sysadmin, FUT til
d.e.sysadmin.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Jeg har haft et hav af problemer med JVM'en, særligt garbage
> collectoren har fået min JVM til at crashe et utal af gange de sidste
> par år. Det lader ikke til at det er noget Sun arbejder så hårdt på at
> fikse, selv om jeg ofte oplever at JVM'en crasher flere gange om ugen.

Interessant. Du er 100% sikker på at du ikke har hardwarefejl - her
tænker jeg specielt på RAM-fejl? Det er serverkvalitethardware du
bruger og alt det der kedelige?

> Men nu, efter jeg skiftede til Java6 er jeg også begyndt at få fejl
> fordi JVM'en løber tør for native heap space selv om den bruger over
> en GB til native heap. Det giver OutOfMemory-exceptions, og nogle
> gange crash.

Det lyder for mig lidt som om at din garbage collector ikke kan følge
trop med applikationen. Kan du eventuelt uddybe lidt hvad der sker og
hvorn den opfører sig - du kan jo overvåge med JMX for at se hvordan
tingene udvikler sig (det er ret rart).

En anden mulighed her iøvrigt at bruge IBM's JVM. De har en lidt
anden holdning til hvordan ting køre.

> Xpost mellem d.e.programmering.java og d.e.sysadmin, FUT til
> d.e.sysadmin.

Den følger jeg ikke, så jeg bliver her.

--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen wrote:
> En anden mulighed her iøvrigt at bruge IBM's JVM. De har en lidt
> anden holdning til hvordan ting køre.

Eller BEA JRockit.

(får ofte meget god omtale for netop mulighederne for
memory forbrugs monitorering)

Arne

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> Jeg har haft et hav af problemer med JVM'en, særligt garbage
>> collectoren [ ... ]
>
> Interessant. Du er 100% sikker på at du ikke har hardwarefejl - her
> tænker jeg specielt på RAM-fejl? Det er serverkvalitethardware du
> bruger og alt det der kedelige?

Ja, to stk. 4-vejs Dell PowerEdge servere i den dyre ende. De er godt
nok ved at være et par år gamle, men de lader til at køre temmelig
stabilt. Jeg har set fejlene fra da de begge var nye. De er købt med
ca. et års mellemrum, så de er nok heller ikke fra samme
produktions-batch. Jeg har ingen grund til at tro at det er
hardwarefejl.

>> Men nu, efter jeg skiftede til Java6 er jeg også begyndt at få fejl
>> fordi JVM'en løber tør for native heap space selv om den bruger over
>> en GB til native heap. Det giver OutOfMemory-exceptions, og nogle
>> gange crash.
>
> Det lyder for mig lidt som om at din garbage collector ikke kan følge
> trop med applikationen.

Jeg har prøvet flere forskellige af de collectorer der findes. Jeg
skrev også om det på tomcat-mailinglisten for et par uger siden. Men
der var ikke rigtig nogen der lod til at have den store
drift-erfaring, de kunne kun pege fingre ad Sun.

Fra dengang ligger der et par filer på http://flof.dk/~jbn/hs_err/

> Kan du eventuelt uddybe lidt hvad der sker og
> hvorn den opfører sig - du kan jo overvåge med JMX for at se hvordan
> tingene udvikler sig (det er ret rart).

Den dør "normalt" med en segmentation fault, men nu også ved at native
heap løber tør for hukommelse så den laver en OutOfMemory exception,
og derefter bare lukker ned og dumper en hs_err_pid-fil (se dem på
ovenstående link).

> En anden mulighed her iøvrigt at bruge IBM's JVM. De har en lidt
> anden holdning til hvordan ting køre.

Er den umiddelbart en drop-in-replacement for Suns JVM? Så kan det
være den er værd at prøve.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Jeg har prøvet flere forskellige af de collectorer der findes. Jeg
> skrev også om det på tomcat-mailinglisten for et par uger siden. Men
> der var ikke rigtig nogen der lod til at have den store
> drift-erfaring, de kunne kun pege fingre ad Sun.

Problemet tror jeg er at Tomcatfolk ganske enkelt sjældent drifter de
RIGTIGT krævende applikationer da disse ofte afvikles under enten en
anden web container, eller en decideret j2ee dimmer.

>
> Fra dengang ligger der et par filer på http://flof.dk/~jbn/hs_err/

Jeg bemærker et mønster der siger Java2D og growable array. Jeg går
naturligvis ud fra at du har masser af ledig hukommelse bla bla bla?

Gider du røbe nok om hvad applikationen laver, til at man kan vurdere
hvorfor den banker hovedet mod loftet, og hvilket resultater du har
med hvilke garbage collectorere?

Altså, fortæl fortæl. Jeg tror nemlig at dit brugsmønster er atypisk
og at det er nøglen til løsningen af dit problem.

> > En anden mulighed her iøvrigt at bruge IBM's JVM. De har en lidt
> > anden holdning til hvordan ting køre.
>
> Er den umiddelbart en drop-in-replacement for Suns JVM? Så kan det
> være den er værd at prøve.

Jep - i min erfaring. Måske skal du justere lidt på dine opstartsflag.

--
Thorbjørn Ravn Andersen

---

Jacob Bunk Nielsen <spam@bunk.cc> wrote in
news:spamdrop+m3abudwr2c.fsf@abbeden.bunk.cc:

> Fra dengang ligger der et par filer på http://flof.dk/~jbn/hs_err/
>
>> Kan du eventuelt uddybe lidt hvad der sker og
>> hvorn den opfører sig - du kan jo overvåge med JMX for at se hvordan
>> tingene udvikler sig (det er ret rart).
>
> Den dør "normalt" med en segmentation fault, men nu også ved at native
> heap løber tør for hukommelse så den laver en OutOfMemory exception,
> og derefter bare lukker ned og dumper en hs_err_pid-fil (se dem på
> ovenstående link).

Hvad er cause i den OutOfMemoryException? Eller hvis du må udlevere det vil
jeg gerne se hele stacktracet.

Heapen er delt op i et antal hukommelsesområder og PermGen er et af dem.
Problemet om man vil er at PermGens størrelse er fast. Når først VM'en er
startet op så står den default til 64MB. Det har ingen indflydelse på
PermGen space at heapens størrelse udvides.

Hvis det er PermGen space den løber tør for så kunne du prøve at bruge
-XX:MaxPermSize
til en sætte mere plads af til PermGen space. Det udskyder selvfølgelig
bare problemet hvis der er en leak i kundens program.


Angående at identificere hvad der kunne være årsagen så kunne du eventuelt
prøve at lave nogle dumps (hvis du fortsat kører Java 6) vha jmap således:
jmap -dump:format=b,file=mitdump 2012
Hvor 2012 er processens pid, det relevante pid kan du evt. finde med jps.

For at læse dit dump kan du bruge jhat.
jhat -J-Xmx512m mitdump

For at se hvad den har parset sig frem til åbner du en webbrowser til
maskinens localhost på port 7000 med mindre du sætter -port parameteren og
angiver en anden ledig port. Via webinterfacet kan du se hvilke objekter
der er i hukommelsen og hvordan de er forbundet.

Derudover kunne du også overveje at bruge nogle profilerværktøjer til at
finde jeres leak: YourKitJavaProfiler, Eclipse TPTP, Trifork P4 (jeg
arbejder som udvikler på Triforks P4 så jeg synes selvfølgelig den er helt
fantastisk :), JProfiler, NetBeans har vist også en - så der skulle være
rig mulighed for at koble sig på og kigge lidt på hvad der egentlig er
loadet når det går galt.

/flemming

---

Flemming Joensson <flemming@joensson.invalid> wrote in
news:Xns99775B225C484flemmingjoensson@130.225.247.90:

> Problemet om man vil er at PermGens størrelse er fast. Når først VM'en
> er startet op så står den default til 64MB.

Dette gælder for Suns JVM - jeg ved ikke hvad JRockit, Oracle og IBM har
som defaultværdier.

/flemming

---

On 03 Jul 2007 18:58:51 +0200
nospam0000@gmail.com (Thorbjørn Ravn Andersen) wrote:

>
> Problemet tror jeg er at Tomcatfolk ganske enkelt sjældent drifter de
> RIGTIGT krævende applikationer da disse ofte afvikles under enten en
> anden web container, eller en decideret j2ee dimmer.
>
Har du erfaring med seneste version af Glassfish?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Michael Rasmussen <mir@miras.org> writes:

> Har du erfaring med seneste version af Glassfish?

Nej. Har haft den kort inde men pt opfylder Jetty de behov jeg har
for en bette, embeddable web container som kan køre under Java 1.4[1].

Horisonten er pt udvidet pga http://cargo.codehaus.org/ som
abstraherer den faktiske implementationn, men de har heller ikke
opdaget Glassfish endnu.

[1] Inertien på IBM-platforme hvor kunderne skal til lommen er meget
meget stor.
--
Thorbjørn Ravn Andersen

---

Jacob Bunk Nielsen wrote:
> Jeg bruger Suns Java6 under Linux, og Apache Tomcat 6 som servlet
> container.

Det ville jag kalde meget nyt til produktion. Jeg ville nok
satse på nyeste 1.5 og 5.5 til produktion.

> Jeg har haft et hav af problemer med JVM'en, særligt garbage
> collectoren har fået min JVM til at crashe et utal af gange de sidste
> par år. Det lader ikke til at det er noget Sun arbejder så hårdt på at
> fikse, selv om jeg ofte oplever at JVM'en crasher flere gange om ugen.

Aldrig hørt om noget sådant.

> Men nu, efter jeg skiftede til Java6 er jeg også begyndt at få fejl
> fordi JVM'en løber tør for native heap space selv om den bruger over
> en GB til native heap. Det giver OutOfMemory-exceptions, og nogle
> gange crash.
>
> Sun har taget imod en bug report:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568433

Har du fået checket hvor den memory leak er henne som de spørger om ?

> Er jeg virkelig den eneste der forsøger at drifte Java applikationer
> der oplever den slags? Jeg synes ikke at Google er fyldt med folk der,
> som jeg har problemer med ustabile JVM'er.

Jeg kan ikke erindre at have hørt om noget lignende.

> Hvordan gør I andre for at holde jeres Java-baserede webapplikationer
> i luften? Er I alle skiftet til 64 bit hardware?

Hvis der er en memory leak så løser 64 bit jo ikke problemet - det
udskyder kun problemet en lille smule.

Arne

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> Fra dengang ligger der et par filer på http://flof.dk/~jbn/hs_err/
>
> Jeg bemærker et mønster der siger Java2D og growable array. Jeg går
> naturligvis ud fra at du har masser af ledig hukommelse bla bla bla?

Ja, men det er jo desværre en 32 bit maskine. Java2D-fejlene er dem
jeg har set længe, dem med OutOfMemory for growable array (og
hashtable) og den slags er først kommet efter jeg gik over til Java6.

> Gider du røbe nok om hvad applikationen laver, til at man kan vurdere
> hvorfor den banker hovedet mod loftet, og hvilket resultater du har
> med hvilke garbage collectorere?

Applikationen laver nogle bioinformatik-beregninger for vores kunder.
Den håndterer en del store filer, men jeg tror ikke der er nogle
alvorlige leaks i den måde vi hopper rundt i filerne.

Nu er det ved at være et stykke tid siden jeg sidst legede med garbage
collectors. De settings jeg fandt frem til var den bedste balance jeg
kunne finde mellem delays på garbage collection og stabilitet.
Skiftede jeg til mere agressive indstillinger crashede den flere gange
dagligt, og med mindre aggresive indstillinger holder den glad pause i
5 minutter for at rydde op.

Som det er nu crasher den et par gange om måneden, men bruger sjældent
mere end 10-20 sekunder på at rydde op.

> Altså, fortæl fortæl. Jeg tror nemlig at dit brugsmønster er atypisk
> og at det er nøglen til løsningen af dit problem.

Ja?

Applikationen bruger nok ofte en masse store objekter, som så skal
ryddes op kort efter, men det forventer jeg egentlig at min JVM tager
sig fornuftigt af, måske lidt hjulpet af mine indstillinger.

>> Er [IBM's JVM] umiddelbart en drop-in-replacement for Suns JVM? Så kan det
>> være den er værd at prøve.
>
> Jep - i min erfaring. Måske skal du justere lidt på dine opstartsflag.

OK - det vil jeg se på når jeg er tilbage fra ferie om et par uger.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Applikationen laver nogle bioinformatik-beregninger for vores kunder.
> Den håndterer en del store filer, men jeg tror ikke der er nogle
> alvorlige leaks i den måde vi hopper rundt i filerne.

Bruger I Java2D under Headless eller ej?

Java2D er lavet - som jeg forstår det - som at Javakoden skovler
informationer ned i en kø som en C-tråd hiver op igen og behandler
passende. Jeg mindes svagt at have set andetsteds at dette for andre
har givet problemer netop med denne slags ting, men kan ikke huske
meget mere end det. Det passer også med at java2d køen bliver for
lang i Java 6 til den kan være der.

HVIS i faktisk _BRUGER_ Java2D til at lave grafer eller lignende og at
det giver mening at I hælder flere data igennem end garbagecollectoren
kan nå at rydde op (hvilket er min mavefornemmelse lige nu), så
overvej at skifte fra headless - især hvis der kan lirkes OpenGL
accelleration på X11-driveren.

> Nu er det ved at være et stykke tid siden jeg sidst legede med garbage
> collectors. De settings jeg fandt frem til var den bedste balance jeg
> kunne finde mellem delays på garbage collection og stabilitet.
> Skiftede jeg til mere agressive indstillinger crashede den flere gange
> dagligt, og med mindre aggresive indstillinger holder den glad pause i
> 5 minutter for at rydde op.

Netbeans har en JVM-performance side hvor de snakker lidt om den
slags. Der nævnes nogen af de nye garbage collectors:

http://performance.netbeans.org/howto/jvmswitches/index.html

> Applikationen bruger nok ofte en masse store objekter, som så skal
> ryddes op kort efter, men det forventer jeg egentlig at min JVM tager
> sig fornuftigt af, måske lidt hjulpet af mine indstillinger.

Kunne du konkretisere "store"?

Jeg synes du skal overvåge din tomcat lidt med jconsole og se om du
kan lure et mønster.

--
Thorbjørn Ravn Andersen

---

Arne Vajhøj <arne@vajhoej.dk> writes:
> Jacob Bunk Nielsen wrote:
>> Jeg bruger Suns Java6 under Linux, og Apache Tomcat 6 som servlet
>> container.
>
> Det ville jag kalde meget nyt til produktion. Jeg ville nok
> satse på nyeste 1.5 og 5.5 til produktion.

Jeg skiftede netop til Java6 i håb om at den var mere stabil. Det er
den også på nogle punkter. Jeg oplever færre crashes fra garbage
collectoren end jeg gjorde tidligere. I stedet oplever jeg nu at den
crasher på grund af at den løber tør for native heap.

>> Sun har taget imod en bug report:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568433
>
> Har du fået checket hvor den memory leak er henne som de spørger om ?

Ja, vi har haft en længere korrespondance på email - jeg ved ikke
hvorfor det ikke er kommet med på websiden.

Den ender med at have over en GB native heap, altså plads som JVM'en
bruger til sig selv før den crasher. Der må næsten være et leak i
JVM'en.

>> Hvordan gør I andre for at holde jeres Java-baserede webapplikationer
>> i luften? Er I alle skiftet til 64 bit hardware?
>
> Hvis der er en memory leak så løser 64 bit jo ikke problemet - det
> udskyder kun problemet en lille smule.

Ja, men så kan man betale sig fra mere RAM der løser problemet for
lang tid af gangen. Det kan jeg ikke på en 32 bit platform

--
Jacob

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> Applikationen laver nogle bioinformatik-beregninger for vores kunder.
>> Den håndterer en del store filer, men jeg tror ikke der er nogle
>> alvorlige leaks i den måde vi hopper rundt i filerne.
>
> Bruger I Java2D under Headless eller ej?

Ja, vi bruger Java2D under headless. Vi bruger det til at lave
PNG-billeder. Det er dog i et relativt overkommeligt antal. Vi har
lavet ca. 1800 PNG-billeder på et par kb stykket på 3 dage - JVM'en
har været nede og vende en gang på grund af at den løb tør for native
heap.

> Java2D er lavet - som jeg forstår det - som at Javakoden skovler
> informationer ned i en kø som en C-tråd hiver op igen og behandler
> passende. Jeg mindes svagt at have set andetsteds at dette for andre
> har givet problemer netop med denne slags ting, men kan ikke huske
> meget mere end det. Det passer også med at java2d køen bliver for
> lang i Java 6 til den kan være der.

Det tror jeg ikke er tilfældet, jo mindre der er en fejl der gør at
den ikke sletter ting fra køen igen. Hmmm.

> HVIS i faktisk _BRUGER_ Java2D til at lave grafer eller lignende og at
> det giver mening at I hælder flere data igennem end garbagecollectoren
> kan nå at rydde op (hvilket er min mavefornemmelse lige nu), så
> overvej at skifte fra headless - især hvis der kan lirkes OpenGL
> accelleration på X11-driveren.

Jeg kan ikke lide at have en X-server kørende på mine servere. Kan
xlibs gøre det?

> Netbeans har en JVM-performance side hvor de snakker lidt om den
> slags. Der nævnes nogen af de nye garbage collectors:
>
> http://performance.netbeans.org/howto/jvmswitches/index.html

Jeg har læst ret meget på:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Det synes jeg faktisk er en fin side, men desværre glemmer de at nævne
problemerne med nogle af de lidt mere eksotiske collectorer.

Så vidt jeg husker er særligt -XX:+UseParNewGC en ballademager. Den så
ellers god ud på papiret.

>> Applikationen bruger nok ofte en masse store objekter, som så skal
>> ryddes op kort efter, men det forventer jeg egentlig at min JVM tager
>> sig fornuftigt af, måske lidt hjulpet af mine indstillinger.
>
> Kunne du konkretisere "store"?

Store som 10 kb, og så måske nogle tusinde af dem puttet i diverse
ArrayList og tilsvarende datastrukturer der kan ændres i størrelse.
Jeg synes ikke det burde ødelægge noget.

> Jeg synes du skal overvåge din tomcat lidt med jconsole og se om du
> kan lure et mønster.

Jeg har ikke prøvet jconsole, tak for tippet. Det vil jeg prøve når
jeg lige har fået overstået den ferie jeg starter på senere i dag

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Jeg kan ikke lide at have en X-server kørende på mine servere. Kan
> xlibs gøre det?

Du skal have selve serveren oppe - det er den der laver
grafikarbejdet. Til gengæld vil du nok konstatere en vis forskel i
afviklingshastighed.

Alternativt så ombyg så PNG-genereringen eventuelt varetages af en
separat JVM, eller lignende.

> Det synes jeg faktisk er en fin side, men desværre glemmer de at nævne
> problemerne med nogle af de lidt mere eksotiske collectorer.

Plus også at jeg tror de ikke er så aftestede som standardversionerne.

> > Kunne du konkretisere "store"?
>
> Store som 10 kb, og så måske nogle tusinde af dem puttet i diverse
> ArrayList og tilsvarende datastrukturer der kan ændres i størrelse.
> Jeg synes ikke det burde ødelægge noget.

Det er ikke store :) Jeg forestillede mig klumper på et par hundrede
megabyte.

> > Jeg synes du skal overvåge din tomcat lidt med jconsole og se om du
> > kan lure et mønster.
>
> Jeg har ikke prøvet jconsole, tak for tippet. Det vil jeg prøve når
> jeg lige har fået overstået den ferie jeg starter på senere i dag

Pjat med dig, du kan tilkoble dig mens den kører.

--
Thorbjørn Ravn Andersen

---

On 2007-07-04, Jacob Bunk Nielsen <spam@bunk.cc> wrote:

(kun postet til dk.edb.programmering.java, da vi efterhånden er et
stykke væk fra sysadmin)

>> Bruger I Java2D under Headless eller ej?
>
> Ja, vi bruger Java2D under headless. Vi bruger det til at lave
> PNG-billeder. Det er dog i et relativt overkommeligt antal. Vi har
> lavet ca. 1800 PNG-billeder på et par kb stykket på 3 dage - JVM'en
> har været nede og vende en gang på grund af at den løb tør for native
> heap.

Jeg ville være ret opmærksom på denne del, Java2D er god til at holde
fast i ting den ikke burde holde fast på, fx streams.
Jeg (og mange andre) er løbet ind i dette under tomcat:
http://nerd.dk/archives/2007/05/31/index.html

Så pas på med at give Java2D for meget adgang til dine egne strukturer,
det lader til at de har en noget længere levetid end først antaget
(måske netop fordi de bliver kastet ned i noget C-kode, som ikke rigtig
følger de gængse GC-konventioner).

Har du mulighed for at splitte PNG-genereringen ud fra resten af app'en,
så det kører i sin egen JVM?

--
Andreas

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> Jeg kan ikke lide at have en X-server kørende på mine servere. Kan
>> xlibs gøre det?
>
> Du skal have selve serveren oppe - det er den der laver
> grafikarbejdet. Til gengæld vil du nok konstatere en vis forskel i
> afviklingshastighed.

Som sagt laver jeg så få billeder at jeg næppe tror jeg vil kunne
mærke forskel.

>> Store som 10 kb, og så måske nogle tusinde af dem puttet i diverse
>> ArrayList og tilsvarende datastrukturer der kan ændres i størrelse.
>> Jeg synes ikke det burde ødelægge noget.
>
> Det er ikke store :) Jeg forestillede mig klumper på et par hundrede
> megabyte.

Njah - nogle af mine hash-tabeller og den slags kan nok løbe op i tæt
på 100 MB i ny og næ.

>> Jeg har ikke prøvet jconsole, tak for tippet. Det vil jeg prøve når
>> jeg lige har fået overstået den ferie jeg starter på senere i dag
>
> Pjat med dig, du kan tilkoble dig mens den kører.

Jeps, det er smart - men den kunne ikke køre på trip-computeren på
motorcyklen. Jeg har lige kort fået prøvet den i går, og må se om jeg
kan få mere ud af den når den værste efter-ferien-travlhed har lagt
sig.

--
Jacob

---

Flemming Joensson <flemming@joensson.invalid> writes:
> Jacob Bunk Nielsen <spam@bunk.cc> wrote:
>
>> Fra dengang ligger der et par filer på http://flof.dk/~jbn/hs_err/
>>
>>> Kan du eventuelt uddybe lidt hvad der sker og
>>> hvorn den opfører sig - du kan jo overvåge med JMX for at se hvordan
>>> tingene udvikler sig (det er ret rart).
>>
>> Den dør "normalt" med en segmentation fault, men nu også ved at native
>> heap løber tør for hukommelse så den laver en OutOfMemory exception,
>> og derefter bare lukker ned og dumper en hs_err_pid-fil (se dem på
>> ovenstående link).
>
> Hvad er cause i den OutOfMemoryException? Eller hvis du må udlevere det vil
> jeg gerne se hele stacktracet.

Har du prøvet at kigge i de filer der ligger på ovenstående URL?

Jeg har ikke andet stracktrace end det der ligger i pågældende filer.
JVM'en lukker jo ned.

> Heapen er delt op i et antal hukommelsesområder og PermGen er et af dem.

Det er jeg med på. Det er bare i JVM'ens egen heap at den løber tør,
ikke i den heap der er tilgængelig for min applikation.

> Hvis det er PermGen space den løber tør for så kunne du prøve at bruge
> -XX:MaxPermSize
> til en sætte mere plads af til PermGen space. Det udskyder selvfølgelig
> bare problemet hvis der er en leak i kundens program.

Det er også mig der er kunden

> Angående at identificere hvad der kunne være årsagen så kunne du eventuelt
> prøve at lave nogle dumps (hvis du fortsat kører Java 6) vha jmap således:
> jmap -dump:format=b,file=mitdump 2012
> Hvor 2012 er processens pid, det relevante pid kan du evt. finde med jps.
>
> For at læse dit dump kan du bruge jhat.
> jhat -J-Xmx512m mitdump

Smart, dem kender jeg ikke - det vil jeg prøve at kigge lidt på.

> Derudover kunne du også overveje at bruge nogle profilerværktøjer til at
> finde jeres leak[...]

Jeg tror altså ikke at mit program har nogle nævneværdige leaks. I
perioder har det kørt i månedsvis på Java5. Andre gange har det
crashet mange gange dagligt med segmentation faults. Out of memory
fejl er noget nyt i Java6 for mit vedkommende.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> wrote in
news:spamdrop+m3myxmx8m3.fsf@abbeden.bunk.cc:

>> Derudover kunne du også overveje at bruge nogle profilerværktøjer til
>> at finde jeres leak[...]
>
> Jeg tror altså ikke at mit program har nogle nævneværdige leaks. I
> perioder har det kørt i månedsvis på Java5. Andre gange har det
> crashet mange gange dagligt med segmentation faults. Out of memory
> fejl er noget nyt i Java6 for mit vedkommende.

Det kunne være at de i 1.6 har fikset et problem der i 1.5 kom til udtryk
som segmentation fault - og at du nu ser det som OutOfMemory fordi JVM
lever videre og når at vise dig en exception?

Angående de filer du havde lagt så har jeg lige kort kigget på dem uden dog
at finde andet end at det som andre siger nok har noget med Java2D at gøre.

/flemming

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Jeg har et setup, hvor jeg forsøger at drive en en Java
> webapplikation, som jeg også selv udvikler på. Jeg forsøger at drive
> det hele på et par 32 bit servere.

Det går stadig ikke helt optimalt. I dag fik jeg denne her:

http://flof.dk/~jbn/hs_err/double-free.txt

Den blev dumpet i min catalina.out, der blev ikke skrevet nogen
hs_err-fil, som der plejer.

Næste gang jeg deployer en ny version af min applikation vil jeg prøve
at starte en X-server og derved undgå Java 2D, som er en af årsagerne
til de hyppige crashes jeg oplever.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Næste gang jeg deployer en ny version af min applikation vil jeg prøve
> at starte en X-server og derved undgå Java 2D, som er en af årsagerne
> til de hyppige crashes jeg oplever.

Det er ikke nok at bruge en X-server (som du skal have adgang til
iøvrigt, Xfb duer, og Xvnc), men du skal også omskrive udenom Java2D.

Som du måske kan se andetsteds har jeg rodet lidt med billedbehandling
de sidste par dage - JAI har vist sig at være vejen frem til det jeg
skal bruge, men det er altså ikke for hvide mennesker. Måske er det
det også for dig?

--
Thorbjørn Ravn Andersen

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> Næste gang jeg deployer en ny version af min applikation vil jeg prøve
>> at starte en X-server og derved undgå Java 2D, som er en af årsagerne
>> til de hyppige crashes jeg oplever.
>
> Det er ikke nok at bruge en X-server (som du skal have adgang til
> iøvrigt, Xfb duer, og Xvnc), men du skal også omskrive udenom Java2D.
>

Hmmm, jeg er ikke sikker på at jeg er helt med. Jeg vil ikke køre en
VNC-server, hvis jeg kan blive fri. Det er trods alt bare en
webapplikation jeg afvikler under Tomcat.

> Som du måske kan se andetsteds har jeg rodet lidt med billedbehandling
> de sidste par dage - JAI har vist sig at være vejen frem til det jeg
> skal bruge, men det er altså ikke for hvide mennesker. Måske er det
> det også for dig?

Jeg bruger allerede JAI - jeg troede det var den der brugte Java2D.
Det er det eneste grafik jeg laver. Den bruger dog nogle AWT klasser,
måske er det der det går galt?

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> > Det er ikke nok at bruge en X-server (som du skal have adgang til
> > iøvrigt, Xfb duer, og Xvnc), men du skal også omskrive udenom Java2D.
> >
>
> Hmmm, jeg er ikke sikker på at jeg er helt med. Jeg vil ikke køre en
> VNC-server, hvis jeg kan blive fri. Det er trods alt bare en
> webapplikation jeg afvikler under Tomcat.

Du skal have en X-server kørende som din JVM kan snakke med og få
udført grafikoperationer - HVILKEN X-server er som sådan ligegyldigt,
bortfra at der måske er noget optimering af en slags der kan udnyttes,
hvad ved jeg.

Den simpleste af slagsen er Xfb.

> Jeg bruger allerede JAI - jeg troede det var den der brugte Java2D.
> Det er det eneste grafik jeg laver. Den bruger dog nogle AWT klasser,
> måske er det der det går galt?

JAI bruger det den får besked på, og det kan være lidt af hvert. Prøv
at undersøge præcis hvorfor du har problemet, måske?
--
Thorbjørn Ravn Andersen

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
> Du skal have en X-server kørende som din JVM kan snakke med og få
> udført grafikoperationer - HVILKEN X-server er som sådan ligegyldigt,
> bortfra at der måske er noget optimering af en slags der kan udnyttes,
> hvad ved jeg.

Nåh, jamen, så tror jeg da bare jeg starter den fra x.org - den er let
at installere for mit vedkommende via apt-get. Det skal jeg nok finde
ud af.

>> Jeg bruger allerede JAI - jeg troede det var den der brugte Java2D.
>> Det er det eneste grafik jeg laver. Den bruger dog nogle AWT klasser,
>> måske er det der det går galt?
>
> JAI bruger det den får besked på, og det kan være lidt af hvert. Prøv
> at undersøge præcis hvorfor du har problemet, måske?

Det er jo lidt bøvlet fordi det langt fra fremkommer konsistent. Jeg
må prøve at skrive lidt stresstest omkring de få Java2D-klasser jeg
bruger.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Det er jo lidt bøvlet fordi det langt fra fremkommer konsistent. Jeg
> må prøve at skrive lidt stresstest omkring de få Java2D-klasser jeg
> bruger.

Nu skrev jeg en test der brugte de klasser der laver billeder, og så
lavede jeg ellers nogle hundrede tusinde forskellige billeder helt og
aldeles uden problemer. Så bedre held med fejlfindingen næste gang.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Nu skrev jeg en test der brugte de klasser der laver billeder, og så
> lavede jeg ellers nogle hundrede tusinde forskellige billeder helt og
> aldeles uden problemer. Så bedre held med fejlfindingen næste gang.

Prøv at lave flere af gangen...
--
Thorbjørn Ravn Andersen

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:

> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> Nu skrev jeg en test der brugte de klasser der laver billeder, og så
>> lavede jeg ellers nogle hundrede tusinde forskellige billeder helt og
>> aldeles uden problemer. Så bedre held med fejlfindingen næste gang.
>
> Prøv at lave flere af gangen...

Så bliver den sur og siger:

*** glibc detected *** double free or corruption (!prev): 0x00002aaaf49aa410 ***
Aborted

.... en fejl jeg også har set flere gange før, og den dukker også op
ret konsistent hvis jeg lader den køre i meget mere end 10 tråde (jeg
tester på en maskine med 4 dual-core CPU'er).

Den dør men skriver ikke nogen hs_err_pid logfil. Jeg må vist lige
prøve at se hvor minimalt et eksempel jeg kan koge det ned til, og så
se at få indgivet en bugreport til Sun.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> Den dør men skriver ikke nogen hs_err_pid logfil. Jeg må vist lige
> prøve at se hvor minimalt et eksempel jeg kan koge det ned til, og så
> se at få indgivet en bugreport til Sun.

Lyder som en god ide. Hvis det ikke opstår når du kun gør det i en
tråd, kan du formentlig lirke dig udenom problemet indtil fejlen
bliver fikset med en passende anvendelse af synchronized.

--
Thorbjørn Ravn Andersen