SLI-1611 Tune the Garbage Collector to avoid high memory usage #1178
Conversation
| return sloopLauncher.start( | ||
| sloopPath, | ||
| Paths.get(jreHomePath), | ||
| "-Xms512m -XX:+UseG1GC -XX:MaxHeapFreeRatio=50 -XX:MinHeapFreeRatio=20" |
There was a problem hiding this comment.
How did we decide on these values?
There was a problem hiding this comment.
I actually did further tuning and found better results with the following:
-Xms384m: SonarLint typically requires at least 200 to 300 MB to start, and grows to 400 or 500 MB during first analysis. Settings this value allows to avoid heap grow cycles at the beginning
-XX:+UseG1GC: This Garbage Collector was found to be the most suitable for our need (low latency & keep memory under control)
-XX:MaxHeapFreeRatio=20 -XX:MinHeapFreeRatio=10: This allows to reduce the heap size without degrading the performance too much (it was tested against other values)
-XX:+UseStringDeduplication: As we store a lot of String with the rules that might be duplicated with multiple connections, I think this is worth to use
-XX:MaxGCPauseMillis=50: For performance reasons, default is 200, at 50 it seems to perform well
-XX:ParallelGCThreads=2: Limit the number of threads used during GC, we don't want SonarLint to use all the threads available for performance reasons
nquinquenel
force-pushed
the
feature/nq/SLI-1611-tune-gc-2
branch
from
8e6a578 to
c6fcaae
Compare
nquinquenel
force-pushed
the
feature/nq/SLI-1611-tune-gc-2
branch
from
c6fcaae to
6c2b7ab
Compare
|
SLI-1611