doc: document how to examine --trace_gc output
#372
Conversation
|
Slightly off topic, perhaps, but is all this information eventually going to end up in https://nodejs.org/en/docs/guides/ ? It'd be a bit more findable there. |
|
@sam-github - yes, according to #211 (comment) and the thread beneath it. |
|
|
||
| ``` | ||
| [PID: isolate] < time taken since GC started in ms> : < type/phase of GC > <heap used before GC call in MB> ( < allocated heap before GC call in MB > ) -> < heap used after GC in MB> ( < allocated heap after GC in MB>) <time spent in GC in ms> [ < reason for GC >] |
There was a problem hiding this comment.
This is hard to read. A graphic where we point to the sections and say what they are might work better.
If we have examples of how to use the traces to identify problems that would also be good. For example in terms of running out of memory. If you first see that that the old space size is continually increasing but it takes too long to hit the max, setting the max old space size to a smaller value can help.
Another one is that if you see that the time spent in GC is continually increasing or is a large portion of the overall that can mean you are short on memory even if you don't OOM.
There was a problem hiding this comment.
@mhdawson, Modified according to your suggestion. PTAL.
| ## 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 ocntinously increasing. |
There was a problem hiding this comment.
| 1. Suppose we observe that the old space is ocntinously increasing. | |
| 1. Suppose we observe that the old space is continously increasing. |
There was a problem hiding this comment.
@mhdawson, thanks. Fixed it.
| 5. Allow the program to run, hit the out of memory. | ||
| 6. The produced log gives shows the failing context. | ||
|
|
||
| B. How to assert whether too many gc are happening or too many gc is causing an overhead |
There was a problem hiding this comment.
| B. How to assert whether too many gc are happening or too many gc is causing an overhead | |
| B. How to assert whether too many gcs are happening or too many gcs are causing an overhead |
There was a problem hiding this comment.
@mhdawson, thanks. Fixed it.
| B. How to assert whether too many gc are happening or too many gc is 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 sseverely starving. |
There was a problem hiding this comment.
| 3. If the time between two gc is less than the time spent in gc, the application is sseverely starving. | |
| 3. If the time between two gc is less than the time spent in gc, the application is severely starving. |
| 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 sseverely starving. | ||
| 4. If the time between two gc and the time spent in gc are very high, probably the application can use a smaller heap |
There was a problem hiding this comment.
| 4. If the time between two gc and the time spent in gc are very high, probably the application can use a smaller heap | |
| 4. If the time between two gcs and the time spent in gc are very high, probably the application can use a smaller heap |
| 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 sseverely starving. | ||
| 4. If the time between two gc and the time spent in gc are very high, probably the application can use a smaller heap | ||
| 5. If the time between two gc is much greater than the time spent in gc, application is relatively healthy |
There was a problem hiding this comment.
| 5. If the time between two gc is much greater than the time spent in gc, application is relatively healthy | |
| 5. If the time between two gcs is much greater than the time spent in gc, application is relatively healthy |
| 3. If the time between two gc is less than the time spent in gc, the application is sseverely starving. | ||
| 4. If the time between two gc and the time spent in gc are very high, probably the application can use a smaller heap | ||
| 5. If the time between two gc is much greater than the time spent in gc, application is relatively healthy | ||
| 6. While the actual numbers for these metrics change from workload to workload, a reasonable gap between gcs is 20 minutes, and a reasonable gc time is < 100 ms. |
There was a problem hiding this comment.
I had the same thought as @Flarna as well. 20 minutes seems to long. Do we have something to back up suggestions for particular numbers?
There was a problem hiding this comment.
No.I don’t have any data / proof points, so I simply removed it.
| 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 gives shows the failing context. | ||
|
|
There was a problem hiding this comment.
We might add another which is similar except we reduce old space size in order to ensure we actually have an OOM. If we see the heap is continually increasing but don't OOM for a long time. Reducing the old space size can help confirm it is an actual leak versus the heap just increasing because there is lots of space and no need to gc or gc aggressively enough.
There was a problem hiding this comment.
@mhdawson, added another example. PTAL.
|
Do we want to document a V8 flag that is not public API and we have no control over it being removed or changed? Edit: nevermind, it's already documented |
it is documented here. |
PR-URL: #372 Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Gerhard Stöbich <[email protected]>
|
landed in 4e8b0bc , thanks for the contribution! |
No description provided.