gcviewer-1.35-SNAPSHOT throws warnings "Unknown gc type" #127
Comments
|
I'd be very interested in your go.log.0. It looks like PrintHeapAtGC prints unexpected output. |
|
Unable to attach, so pasting lines as is again: |
chewiebug
added a commit
that referenced
this issue
Jan 16, 2015
|
I have pushed a fix to the repository and built the latest SNAPSHOT release. Does it work now? |
|
Checking.
|
|
Awesome works now and able to see them, wonder if there is a way to get event details when I click a data point or "at least the exact time when the event happened on top" instead of hours elapsed so I can back track the spikes in my logs. |
|
Also awesome would be to adjust the time scale as few outliers (> few seconds) can completely mess up the plot. |
|
Our GC configuration is pretty simple and uses fixed values instead of variable ranges, not sure when variable ranges to let JVM decide the sizes would make more sense? Anyways, in our write/read intensive cassandra with some caching, we noticed our (all the way below) 14 GB heap, new ratio=2, tenuringThreshold=10 and survivor ratio=8 or about 250 MB is working fine because most read data generated garbage remains in survivor stays for a long time to reach 250 MB at >80% of the time, but is this a good idea to keep such read related data and cache in survivor spaces as very little amount 40 MB alone is filled up in survivor space? In this case there is no point in increasing survivor space as we don’t fill up but what about increasing tenured ratio to > 15, is it ok to live with 20-40ms par new GCs every half a min or reduce this size and tenuring ratio as most of the time only about 1-10 MB is surviving and flushed to old gen.
-XX:+UseThreadPriorities |
|
Wanted to use GCViewer to understand this one outlier, however, I still don't understand why the GC times are more than 4 seconds here although two CMS seem to happen and complete without any problem and the heap really did not hit the full limit? |
|
Thanks - I am happy to know, there are poeple out there, who have a There is already a feature request for showing exact details, when Concerning your tuning question: I'd need to have the part of your log, Do you happen to know hotspot-gc-use@openjdk.java.net? That's the Best regards, |
|
Just sent, thanks. |
|
I close this issue, since the GCViewer related part is fixed. |
|
Thanks, curious why are the full GCs showing up as 0 although there are CMS GCs and ParNew GCs which are both stop the world. |
|
The FullGC counter is for real FullGCs, not for "any GC which has a pause phase". In case of CMS you have 3 types of GC, the parallel copy GC in young generation, the mostly concurrent parallel in old generation. And only if a promotion error happens it will do a FullGC. And this is very bad, as it uses the single threaded SerialGC for this. Oldie but goodie: https://blogs.oracle.com/jonthecollector/entry/our_collectors BTW: the term "Full" used to have different meanings including "stop the world" or "old generation" or "all generations". Its best to not think in these terms. |
|
Makes sense, keep getting confused between Full GCs vs Stop The World mark/remark/par new GCs. Apparently, could not quickly google to find valid Java source that clearly explained "Full GC". I do remember Full GCs happen when sizes expand too. Is this applicable for Young generation expansion too when we specify NewSize and MaxNewSize? Again, could not confirm this anywhere online. Glad to know that we don't have Full GCs but really long CMS when there is lot of promotion during busy periods. Still trying to figure out an optimal tuning for our long CMS GCs. |
|
As Bernd explained, it is somewhat up to the reader of a gc log, what he The compartment "Concurrent GCs" shows information about concurrent In CMS, no full gc events are needed to resize the heap. I observe |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Just gave it a try and ended up getting lot of warnings.
java -jar gcviewer-1.35-SNAPSHOT.jar gc.log.0 summary.csv chart.png -t CSV_TS
gc logs generated as follows: /usr/java/jre1.7.0_51//bin/java -ea -javaagent:/usr/share/dse/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms14G -Xmx14G -XX:+HeapDumpOnOutOfMemoryError -XX:NewRatio=2 -XX:MaxTenuringThreshold=10 -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseTLAB -XX:+UseCondCardMark -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintPromotionFailure -XX:PrintFLSStatistics=1 -Xloggc:/var/log/cassandra/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=64M
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'concurrent mark-sweep generation total' Line 309835: concurrent mar
k-sweep generation total 9786752K, used 6660868K [0x00000005a58a0000, 0x00000007fae00000, 0x00000007fae00000)
Jan 16, 2015 1:41:06 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'concurrent-mark-sweep perm gen total' Line 309836: concurrent-mark-
sweep perm gen total 83968K, used 51110K [0x00000007fae00000, 0x0000000800000000, 0x0000000800000000)
Jan 16, 2015 1:41:06 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.ParseException: Error parsing entry (java.lang.ArrayIndexOutOfBoundsException) Line 309837: }
Jan 16, 2015 1:41:06 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'GCHeap after GC invocations=' Line 309892: 2015-01-10T22:38:37.116+0
000: 81720.358: [GCHeap after GC invocations=4682 (full 16):
Jan 16, 2015 1:41:06 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'par new generation total' Line 309893: par new generation total
4404032K, used 63139K [0x000000047ae00000, 0x00000005a58a0000, 0x00000005a58a0000)
Jan 16, 2015 1:41:06 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'eden space' Line 309894: eden space 3914752K, 0% used [0x0000000
47ae00000, 0x000000047ae00000, 0x0000000569d00000)
Jan 16, 2015 1:41:06 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'from space' Line 309895: from space 489280K, 12% used [0x00000005
69d00000, 0x000000056daa8eb8, 0x0000000587ad0000)
Jan 16, 2015 1:41:07 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'to space' Line 309896: to space 489280K, 0% used [0x00000005
87ad0000, 0x0000000587ad0000, 0x00000005a58a0000)
Jan 16, 2015 1:41:07 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'concurrent mark-sweep generation total' Line 309897: concurrent mar
k-sweep generation total 9786752K, used 6663249K [0x00000005a58a0000, 0x00000007fae00000, 0x00000007fae00000)
Jan 16, 2015 1:41:07 AM com.tagtraum.perf.gcviewer.imp.DataReaderSun1_6_0 read
WARNING: com.tagtraum.perf.gcviewer.imp.UnknownGcTypeException: Unknown gc type: 'concurrent-mark-sweep perm gen total' Line 309898: concurrent-mark-
sweep perm gen total 83968K, used 51110K [0x00000007fae00000, 0x0000000800000000, 0x0000000800000000)
The text was updated successfully, but these errors were encountered: