@@ -8,7 +8,8 @@ layout: docs.hbs
8
8
There's a lot to learn about how the garbage collector works, but if you learn
9
9
one thing it's that when GC is running, your code is not.
10
10
11
- You may want to know how often and how long the garbage collection is running.
11
+ You may want to know how often and how long the garbage collection is running,
12
+ and what is the outcome.
12
13
13
14
## Runnig with garbage collection traces
14
15
@@ -20,7 +21,8 @@ $ node --trace_gc app.js
20
21
```
21
22
22
23
You might want to avoid getting traces from the entire lifetime of your
23
- process running on a server. In that case, set the flag from within the process.
24
+ process running on a server. In that case, set the flag from within the process,
25
+ and switch it off once the need for tracing is over.
24
26
25
27
Here's how to print GC events to stdout for one minute.
26
28
@@ -92,7 +94,7 @@ This is how to interpret the trace data (for the second line):
92
94
93
95
## Using performance hooks to trace garbage collection
94
96
95
- For Node.js v8.5.0 or later , you can use [ performance hooks] [ ] to trace
97
+ In Node.js, you can use [ performance hooks] [ ] to trace
96
98
garbage collection.
97
99
98
100
``` js
@@ -177,7 +179,7 @@ For more information, you can refer to
177
179
178
180
A. How to get context of bad allocations
179
181
1 . Suppose we observe that the old space is continously increasing.
180
- 2 . But due to heavy gc, the heap roof is not hit, but the process is slow.
182
+ 2 . But due to heavy gc, the heap maximum is not hit, but the process is slow.
181
183
3 . Review the trace data and figure out how much is the total heap before and
182
184
after the gc.
183
185
4 . Reduce ` --max-old-space-size ` such that the total heap is closer to the
@@ -187,7 +189,7 @@ limit.
187
189
188
190
B. How to assert whether there is a memory leak when heap growth is observed
189
191
1 . Suppose we observe that the old space is continously increasing.
190
- 2 . Due to heavy gc, the heap roof is not hit, but the process is slow.
192
+ 2 . Due to heavy gc, the heap maximum is not hit, but the process is slow.
191
193
3 . Review the trace data and figure out how much is the total heap before and
192
194
after the gc.
193
195
4 . Reduce ` --max-old-space-size ` such that the total heap is closer to the
@@ -196,7 +198,7 @@ limit.
196
198
6 . If it hits OOM, increment the heap size by ~ 10% or so and repeat few times.
197
199
If the same pattern is observed, it is indicative of a memory leak.
198
200
7 . If there is no OOM, then freeze the heap size to that value - A packed heap
199
- reduces memory footprint and compation latency.
201
+ reduces memory footprint and compaction latency.
200
202
201
203
C. How to assert whether too many gcs are happening or too many gcs are causing
202
204
an overhead
0 commit comments