Hey all, me again. I'm still investigating the pauses that I get when a soft commit happens. I'm now convinced they're coming from G1GC pauses that happen when the soft commit happens and wondering if anyone can see what's up. Caveat: I'm no JVM expert.
I've uploaded a small time window to gceasy and the latency spikes we see correlate to young gen completely emptying (which is I presume as a result of the new searcher loading?) https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjAvMDIvMS8tLWdjLXNvbHItMy0yMDIwXzAyXzAxLTE1XzA2LmxvZy0tMTUtNTItNDA=&channel=WEB Here's one of the longer pauses. The only thing that stands out to me is that it's getting rid of a lot more Eden region than the other pauses [1294.080s][info ][gc,start ] GC(369) Pause Young (Normal) (G1 Evacuation Pause) [1294.080s][info ][gc,task ] GC(369) Using 8 workers of 8 for evacuation [1294.080s][debug][gc,age ] GC(369) Desired survivor size 785173704 bytes, new threshold 1 (max threshold 1) [1294.194s][trace][gc,age ] GC(369) Age table with threshold 1 (max threshold 1) [1294.194s][trace][gc,age ] GC(369) - age 1: 128787840 bytes, 128787840 total [1294.194s][info ][gc,mmu ] GC(369) MMU target violated: 51.0ms (50.0ms/51.0ms) [1294.194s][info ][gc,phases ] GC(369) Pre Evacuate Collection Set: 0.2ms [1294.194s][info ][gc,phases ] GC(369) Evacuate Collection Set: 110.7ms [1294.194s][info ][gc,phases ] GC(369) Post Evacuate Collection Set: 3.4ms [1294.194s][info ][gc,phases ] GC(369) Other: 0.5ms [1294.194s][info ][gc,heap ] GC(369) Eden regions: 397->0(217) [1294.194s][info ][gc,heap ] GC(369) Survivor regions: 19->8(52) [1294.194s][info ][gc,heap ] GC(369) Old regions: 1340->1359 [1294.194s][info ][gc,heap ] GC(369) Humongous regions: 2->2 [1294.194s][info ][gc,metaspace ] GC(369) Metaspace: 56772K->56772K(1101824K) [1294.194s][info ][gc ] GC(369) Pause Young (Normal) (G1 Evacuation Pause) 28120M->21883M(31744M) 114.912ms [1294.194s][info ][gc,cpu ] GC(369) User=0.67s Sys=0.23s Real=0.11s [1294.195s][info ][gc,stringdedup] Concurrent String Deduplication (1294.195s) [1294.196s][info ][gc,stringdedup] Concurrent String Deduplication 106.2K->15696.0B(93032.0B) avg 84.1% (1294.195s, 1294.196s) 1.397ms We're using the following settings: The machine has 64gb RAM, 31gb heap. The core we're constantly querying and updating is 40GB. It's got a soft auto commit every 10 minutes. export GC_TUNE="-XshowSettings:vm \ -XX:+UnlockExperimentalVMOptions \ -XX:+ExitOnOutOfMemoryError \ -XX:+UseG1GC \ -XX:+PerfDisableSharedMem \ -XX:+ParallelRefProcEnabled \ -XX:G1MaxNewSizePercent=30 \ -XX:G1NewSizePercent=6 \ -XX:G1HeapRegionSize=16M \ -XX:G1HeapWastePercent=10 \ -XX:G1MixedGCCountTarget=16 \ -XX:InitiatingHeapOccupancyPercent=70 \ -XX:MaxGCPauseMillis=50 \ -XX:-ResizePLAB \ -XX:MaxTenuringThreshold=1 \ -XX:ParallelGCThreads=8 \ -XX:ConcGCThreads=2 \ -XX:TargetSurvivorRatio=90 \ -XX:+UseStringDeduplication" Any advice would be greatly appreciated! This e-mail is sent on behalf of Auto Trader Group Plc, Registered Office: 1 Tony Wilson Place, Manchester, Lancashire, M15 4FN (Registered in England No. 9439967). This email and any files transmitted with it are confidential and may be legally privileged, and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This email message has been swept for the presence of computer viruses.
