Suggestions for reducing unnecessary Scavenge Garbage Collector calls, since GC is blocking code quite many times.

[mai1x9]

Hi there,
Could anyone please suggest on how to reduce frequent GC calls made by node (by writing better code, decreasing object allocations etc..).?

Looks like Scavenge GC calls are pretty fast and occurs more often than mark sweep, however, more number of GC calls made by Scavenge is blocking the code. After some research, I could understand that scavenge GC is called when max semi space allocated exceeds. I believe lesser memory allocations would less often call GC.

---

Regarding Application:
It is backend service using express. On LoadTesting with Concurrent users of 1000, with 20K requests,I could see GC calls by Scavenge is occurring very often and blocking the event loop, hence request latency is increased.

Would like to know any suggestions, like How to reduce unnecessary memory allocations, optimising loops where objects created in loop might be responsible for high memory raise, etc etc..

---

On Side Note,

• I the application is tested for memory leaks, as such there wasn't any memory leak, as heap used is resetting to stable 100 Mb after Mark sweep GC call(initial value of heap used when application ran).
• I have changed max semi space to 64 MB, but that have result in much worst results, since scavenge operation is now taking more time than default, when gc call happens.

Is it a known fact that under excessive loadtesting of server, memory does increase and very often GC calls happen?

[bnoordhuis]

You don't know at this point how much CPU time is spent inside the garbage collector so my suggestion is to profile your application first.

[mai1x9]

Hi @bnoordhuis after cpu profiling (from browser dev tools and running node with --inspect), I could get cpu timespent by GC. Regarding the loadtest, 200 concurrent users and 5k requests sent to server build using express framework. I am enclosing the results (After sorting out cpu time),

Looks like GC took around 1 second cpu time. I wonder if these results are per requests or cumulative time for all 5k requests during the course of run. Can I say that GC is not effecting the application performance badly and is negligible.?

[bnoordhuis]

That's cumulative and 2.4% is indeed quite insignificant.

[mai1x9]

@bnoordhuis thanks for the clarification. I would mark it as answered. Out of curiosity, why does processTicksAndRejections and callbackTrampoline takes lot of cpu utilisation.

Reference:

Is it the node internals using cpu% or issue in the code, where setTimeouts, or Promises/callbacks in the code is doing cpu intensive tasks. I tried to search some blogs but no clear cut explanation. Would be great if you can clarify on this?

[bnoordhuis]

You've sorted by total time, not self time. Total time = self time + self time of callees. It's not processTicksAndRejections() and callbackTrampoline() that take up a lot of CPU time but the callbacks/promises they invoke.

[mai1x9]

@bnoordhuis please refer to below images, looks like gc is using high cpu % (around 65%+ too recorded), and high gc is recorded when server has no load, is it because server has no load, max time appears to be spend on gc than processing requests and hence higher cpu %? Is it because of mark sweep run ? The results captured are after load testing and i could observe mark sweep was run (using gc-stats npm module). Just what to confirm ok, since it would be just a spike during profiling was done?

[bnoordhuis]

In your screenshot GC looks outsized in isolation but it's only 1% of wall clock time. Nothing to lose sleep over. :-)

[bnoordhuis]

@mai1x9 You marked one of your questions as the answer but, for the benefit of people coming here from search engines, you probably want to pick one of my replies.

[mai1x9]

sorry for that. I have marked one of your answers.