diff --git a/documentation/memory/step3/using_gc_traces.md b/documentation/memory/step3/using_gc_traces.md index 992b9f9..afeb39e 100644 --- a/documentation/memory/step3/using_gc_traces.md +++ b/documentation/memory/step3/using_gc_traces.md @@ -20,4 +20,89 @@ v8.setFlagsFromString('--trace_gc'); setTimeout(() => { v8.setFlagsFromString('--notrace_gc'); }, 60e3); ``` -## Examining a trace \ No newline at end of file +## Examining a trace + +Obtained traces of garbage collection looks like the following lines. + +``` +[19278:0x5408db0] 44 ms: Scavenge 2.3 (3.0) -> 1.9 (4.0) MB, 1.2 / 0.0 ms (average mu = 1.000, current mu = 1.000) allocation failure + +[23521:0x10268b000] 120 ms: Mark-sweep 100.7 (122.7) -> 100.6 (122.7) MB, 0.15 / 0.0 ms (average mu = 0.132, current mu = 0.137) deserialize GC in old space requested +``` + +This is how to interpret the trace data (for the second line): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Token valueInterpretation
23521PID of the running process
0x10268db0Isolate (JS heap instance)
120Time since the process start in ms
Mark-sweepType / Phase of GC
100.7Heap used before GC in MB
122.7Total heap before GC in MB
100.6Heap used after GC in MB
122.7Total heap after GC in MB
0.15 / 0.0
+ (average mu = 0.132, current mu = 0.137)		Time spent in GC in ms
deserialize GC in old space requestedReason for GC
+ +## Examples of diagnosing memory issues with trace option: + +A. How to get context of bad allocations using --trace-gc + 1. Suppose we observe that the old space is continously increasing. + 2. But due to heavy gc, the heap roof is not hit, but the process is slow. + 3. Review the trace data and figure out how much is the total heap before and after the gc. + 4. Reduce `--max-old-space-size` such that the total heap is closer to the limit. + 5. Allow the program to run, hit the out of memory. + 6. The produced log shows the failing context. + +B. How to assert whether there is a memory leak when heap growth is observed + 1. Suppose we observe that the old space is continously increasing. + 2. Due to heavy gc, the heap roof is not hit, but the process is slow. + 3. Review the trace data and figure out how much is the total heap before and after the gc. + 4. Reduce --max-old-space-size such that the total heap is closer to the limit. + 5. Allow the program to run, see if it hits the out of memory. + 6. If it hits OOM, increment the heap size by ~10% or so and repeat few times. If the same pattern is observed, it is indicative of a memory leak. + 7. If there is no OOM, then freeze the heap size to that value - A packed heap reduces memory footprint and compation latency. + +C. How to assert whether too many gcs are happening or too many gcs are causing an overhead + 1. Review the trace data, specifically around time between consecutive gcs. + 2. Review the trace data, specifically around time spent in gc. + 3. If the time between two gc is less than the time spent in gc, the application is severely starving. + 4. If the time between two gcs and the time spent in gc are very high, probably the application can use a smaller heap. + 5. If the time between two gcs are much greater than the time spent in gc, application is relatively healthy. +