History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-3015
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Robin Shen
Reporter: AlSt
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
QuickBuild

Rethink the use of System.gc()

Created: 18/Jul/17 05:50 AM   Updated: 22/Jul/17 01:56 AM
Component/s: None
Affects Version/s: 7.0.19
Fix Version/s: 7.0.20

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown


 Description  « Hide
Hi!

Our QB server is running on 24 GB heap with Java 8. We use the G1GC which is usually performing great with such big Xmx value. We also use string deduplication which is done by the G1GC.

And since we upgraded from 6.x to 7.x we had very high GC suspension times (50% of the time was suspension time by the GC) and QB only used between 1 and 2 GB of heap even though it had 24 GB it could have used. So I dug through the QB source and found a lot of System.gc() calls (like on file operations, batch jobs, ...). At this time I knew that this causes this odd behavior. So I had to do a emergency restart of QB and applied the setting "-XX:+DisableExplicitGC" and after that the JVM just takes care of running the GC and it is working like a charm.

Anyway: Doing explicit GC calls is bad practice and causes more troubles than it solves issues.

So please rethink the use of explicit GC calls (System.gc()). There are a lot of resources out there which explain why explicit calls to GC should be avoided.

Thanks, Alex

 All   Comments   Work Log   Change History      Sort Order:
Robin Shen [18/Jul/17 12:46 PM]
Thanks, will get it fixed in next patch release.