Patton Skrevet 29. juni 2012 Del Skrevet 29. juni 2012 Hei, Jeg har et problem med et java-program, som fryser av og til når den gjennomgår en full-gc. Jeg tror det pga Windows XP paging, men for å være 100% sikker så ønsker jeg å finne ut hva som blir skrevet til page-file og hentet tilbake til ethvert tidspunkt. Spesielt viktig er det å finne ut når JVM (java virtual machine) henter data fra page-filen og når Windows skriver deler av JVM til page-file. Noen som har noen tips om hvordan jeg kan løse dette? Lenke til kommentar
GeirGrusom Skrevet 29. juni 2012 Del Skrevet 29. juni 2012 Hvordan vet du at det skjer under GC? Hva får deg til å tro at det har noe som helst med paging å gjøre? Performance Monitor kan kartlegge ihvertfall hvor mye som blir skrevet til page filen. Lenke til kommentar
Patton Skrevet 29. juni 2012 Forfatter Del Skrevet 29. juni 2012 Fra min gc-log: 630634.684: [GC 630634.684: [DefNew: 27437K->595K(27520K), 0.0200058 secs]630634.704: [Tenured: 366748K->188572K(366848K), 15.0305900 secs] 391289K->188572K(394368K), [Perm : 39137K->39047K(39168K)], 15.0512696 secs] [Times: user=0.94 sys=0.56, real=15.06 secs] Her ser du at JVM'en hadde en 15 sekunder pause (full gc, der Tenured blir ryddet opp). Jeg har sjekket gc-grafen, og den ser helt normal ut inklusiv denne gc'en, bortsett fra pauselengden (de er alle rundt 0.6-1.0 sekunder). Et utsnitt: 595888.471: [GC 595888.471: [DefNew: 25872K->271K(27520K), 0.0120035 secs]595888.483: [Tenured: 366633K->207880K(366720K), 0.6360032 secs] 391409K->207880K(394240K), [Perm : 38812K->38812K(38912K)], 0.6487084 secs] [Times: user=0.66 sys=0.00, real=0.66 secs] 603153.299: [GC 603153.300: [DefNew: 26358K->1505K(27520K), 0.0140728 secs]603153.314: [Tenured: 365659K->207563K(365696K), 0.6404681 secs] 391635K->207563K(393216K), [Perm : 38817K->38817K(38912K)], 0.6551141 secs] [Times: user=0.66 sys=0.00, real=0.66 secs] 610410.312: [GC 610410.312: [DefNew: 26661K->1072K(27520K), 0.0158483 secs]610410.328: [Tenured: 366238K->188269K(366336K), 0.9558888 secs] 391671K->188269K(393856K), [Perm : 38875K->38798K(38912K)], 0.9724601 secs] [Times: user=0.81 sys=0.00, real=0.97 secs] 621402.037: [GC 621402.037: [DefNew: 26807K->1020K(27520K), 0.0170886 secs]621402.055: [Tenured: 365710K->186377K(365824K), 0.6642687 secs] 391110K->186377K(393344K), [Perm : 38847K->38811K(38912K)], 0.6819461 secs] [Times: user=0.69 sys=0.00, real=0.69 secs] 629082.588: [GC 629082.588: [DefNew: 27289K->592K(27520K), 0.0186306 secs]629082.607: [Tenured: 368366K->201103K(368384K), 0.8589075 secs] 392894K->201103K(395904K), [Perm : 39112K->39112K(39168K)], 0.8782451 secs] [Times: user=0.67 sys=0.00, real=0.89 secs] Når real er mange ganger større enn user+sys tilsammen, betyr det at garbage collectoren er blokkert og venter (høyst sannsynligvis pga I/O). Jeg ser Windows paging som den mest sannsynlige grunnen til pausen, siden gc aksesserer minnet og den eneste I/O operasjonen som kunne blokkere minnetilgang så lenge er lesing fra HDD. Kanskje du har andre ideer? Lenke til kommentar
GeirGrusom Skrevet 2. juli 2012 Del Skrevet 2. juli 2012 Men da ville vel problemet også vært tilstede i alle andre programmer. Det pleier å være mest produktivt å skylde på selve programmet, enn å skylde på operativsystemet. Virker kanskje veldig søkt, men en semafor i en finalizer kunne ført til samme problemet. Men jeg har ikke egentlig noen gode forslag. Performance Monitor kan ihvertfall kartlegge page faults, så du kan jo se om det sammenfaller med problemet. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå