From 2efaaf6af39c20abeb69be03a265d9458aa800cf Mon Sep 17 00:00:00 2001 From: RafaelGSS Date: Tue, 19 Jul 2022 09:40:26 -0300 Subject: [PATCH] guide: apply review suggestions --- locale/en/docs/guides/diagnostics/index.md | 2 +- locale/en/docs/guides/diagnostics/memory/index.md | 3 ++- .../guides/diagnostics/memory/using-gc-traces.md | 14 ++++++++------ .../diagnostics/memory/using-heap-profiler.md | 2 +- .../diagnostics/memory/using-heap-snapshot.md | 5 +++-- 5 files changed, 15 insertions(+), 11 deletions(-) diff --git a/locale/en/docs/guides/diagnostics/index.md b/locale/en/docs/guides/diagnostics/index.md index c04c8bfe055a8..713f170f8c0d6 100644 --- a/locale/en/docs/guides/diagnostics/index.md +++ b/locale/en/docs/guides/diagnostics/index.md @@ -9,7 +9,7 @@ These guides were created in the [Diagnostics Working Group](https://github.com/ with the objective to provide a guidance when diagnosing an issue in the user application. The documentation project is organized based on user journey. -Those journeys are coherent set of step-by-step procedures, +Those journeys are a coherent set of step-by-step procedures, that a user follows for problem determination of reported issues. This is the available set of diagnostics guides: diff --git a/locale/en/docs/guides/diagnostics/memory/index.md b/locale/en/docs/guides/diagnostics/memory/index.md index 2abb3e9da8dca..669f984a5f335 100644 --- a/locale/en/docs/guides/diagnostics/memory/index.md +++ b/locale/en/docs/guides/diagnostics/memory/index.md @@ -36,7 +36,8 @@ restarts make certain requests to fail _(load balancer responds with 502)_. * Process restarts due to the memory exhaustion and request are dropped on the floor * Increased GC activity leads to higher CPU usage and slower response time -* Increased memory swapping slows down the process + * GC blocking the Event Loop causing slowness +* Increased memory swapping slows down the process (GC activity) * May not have enough available memory to get a Heap Snapshot ### Debugging diff --git a/locale/en/docs/guides/diagnostics/memory/using-gc-traces.md b/locale/en/docs/guides/diagnostics/memory/using-gc-traces.md index c68de59633714..b86169e55f99a 100644 --- a/locale/en/docs/guides/diagnostics/memory/using-gc-traces.md +++ b/locale/en/docs/guides/diagnostics/memory/using-gc-traces.md @@ -8,7 +8,8 @@ layout: docs.hbs There's a lot to learn about how the garbage collector works, but if you learn one thing it's that when GC is running, your code is not. -You may want to know how often and how long the garbage collection is running. +You may want to know how often and how long the garbage collection is running, +and what is the outcome. ## Runnig with garbage collection traces @@ -20,7 +21,8 @@ $ node --trace_gc app.js ``` You might want to avoid getting traces from the entire lifetime of your -process running on a server. In that case, set the flag from within the process. +process running on a server. In that case, set the flag from within the process, +and switch it off once the need for tracing is over. Here's how to print GC events to stdout for one minute. @@ -92,7 +94,7 @@ This is how to interpret the trace data (for the second line): ## Using performance hooks to trace garbage collection -For Node.js v8.5.0 or later, you can use [performance hooks][] to trace +In Node.js, you can use [performance hooks][] to trace garbage collection. ```js @@ -177,7 +179,7 @@ For more information, you can refer to A. How to get context of bad allocations 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. +2. But due to heavy gc, the heap maximum 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 @@ -187,7 +189,7 @@ limit. 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. +2. Due to heavy gc, the heap maximum 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 @@ -196,7 +198,7 @@ limit. 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. +reduces memory footprint and compaction latency. C. How to assert whether too many gcs are happening or too many gcs are causing an overhead diff --git a/locale/en/docs/guides/diagnostics/memory/using-heap-profiler.md b/locale/en/docs/guides/diagnostics/memory/using-heap-profiler.md index 1f1d100a0d0c3..03915402fa27d 100644 --- a/locale/en/docs/guides/diagnostics/memory/using-heap-profiler.md +++ b/locale/en/docs/guides/diagnostics/memory/using-heap-profiler.md @@ -38,7 +38,7 @@ node --inspect index.js > `--inspect-brk` is an better choice for scripts. -Connect to the dev-tools instance and then: +Connect to the dev-tools instance in chrome and then: * Select `memory` tab * Select `Allocation instrumentation timeline` diff --git a/locale/en/docs/guides/diagnostics/memory/using-heap-snapshot.md b/locale/en/docs/guides/diagnostics/memory/using-heap-snapshot.md index f20e832561011..a4ba8cc06abc6 100644 --- a/locale/en/docs/guides/diagnostics/memory/using-heap-snapshot.md +++ b/locale/en/docs/guides/diagnostics/memory/using-heap-snapshot.md @@ -6,12 +6,12 @@ layout: docs.hbs # Using Heap Snapshot You can take a Heap Snapshot from your running application and load it into -Chrome Developer Tools to inspect certain variables or check retainer size. +[Chrome Developer Tools][] to inspect certain variables or check retainer size. You can also compare multiple snapshots to see differences over time. ## Warning -To create a snapshot, all other work in your main thread is stopped. +When creating a snapshot, all other work in your main thread is stopped. Depending on the heap contents it could even take more than a minute. The snapshot is built in memory, so it can double the heap size, resulting in filling up entire memory and then crashing the app. @@ -158,3 +158,4 @@ Practice capturing heap snapshots and finding memory leaks with [load button image]: /static/images/docs/guides/diagnostics/load-snapshot.png [comparison image]: /static/images/docs/guides/diagnostics/compare.png [heapsnapshot exercise]: https://github.com/naugtur/node-example-heapdump +[Chrome Developer Tools]: https://developer.chrome.com/docs/devtools/