Analysis of memory leaks in Angular applications running in SSR mode

Angular applications running in SSR mode, in order to avoid the Flickering problem of the screen caused by calling the same API twice on the server side and the client side, the Angular TransferState service is used to send information from the server to the client, which The working principle is shown in the following figure:

First import ---b2d67b66007e7cb35586d2f5a806e49c--- in the application app.module.ts BrowserTransferStateModule :

 import { BrowserModule, BrowserTransferStateModule } from '@angular/platform-browser';
imports: [
  BrowserModule.withServerTransition({appId: 'my-app'}),
  BrowserTransferStateModule,
  ...
]

Then import ServerTransferStateModule in the server-side module app.server.module.ts 738cffaac5eb8da9cfd1b32de94cad4b---:

 import { ServerModule, ServerTransferStateModule } from '@angular/platform-server';
imports: [
  AppModule,
  ServerModule,
  ServerTransferStateModule,
  ...
]

We can use the makeStateKey function to create a key to store the data in the state (which will be passed to the browser). Use this.state.get to get data from state, and use this.state.set to set data in state. When the API call is made, the returned data is stored in Angular state using the key created by the previous call to makeStateKey.

A Spartacus SSR application using the TransferState service usually has the following symptoms when a memory leak occurs:

• User request response time increased
• jsapps pods restart frequently
• The following log appears when running:

(1) SSR rendering exceeded timeout 3000, fallingbacking to CSR for /xyz
(2) PM2 Process 0 restarted because it exceeds --max-memory-restart value (current_memory=4009730048 max_memory_limit=3865051136 [octets])
(3) Rendering of /xyz was not able to complete. This might cause memory leaks!

If one of the above symptoms occurs, we can use Dynatrace to analyze the cause of the memory leak.

In Dynatrace, each SSR pod can be found from the Technologies and Processes option and Node.js Technologies in the left navigation menu. The process group will have the name of the main file containing your application's SSR, usually main.js or server.js. Clicking on the latter will list the pods that were active during the specified time frame, allowing us to access the process details page for any individual pod.

At a high level, just looking at the V8 heap memory graph in Dynatrace can make an informed judgement about the likelihood of a memory leak. The most obvious signs of a potential memory leak in Node.js are:

1. V8 heap memory spikes (sharp spike)
2. After each pod restart, the memory usage graph will peak 再次

Typically, a sawtooth pattern like the one shown below ( saw tooth ) seems to indicate a healthy application, since it is assumed that every free in memory happens due to garbage collection. However, if you find that every spike in memory is followed by a memory release that is simply due to a pod restart, then the app is likely to have a memory leak.

If we increase the system's available memory, but the sawtooth pattern observed in Dynatrace persists, this performance is more of a strong evidence that the application has a memory leak.