In Acquia Node.js Hosting, memory limit of 1.8GB is assigned to each Node.js process. If a process tries to claim more than the assigned memory, the platform restarts the Node.js process forcefully. It usually happens because of memory leak in the application.
This document provides a series of necessary steps to identify, troubleshoot, and resolve memory leaks in Node.js applications hosted on Cloud Platform. While it does not focus on troubleshooting performance issues in JavaScript applications, the methods presented may also assist in addressing these concerns.
The following are the methods to identify memory leaks in Node.js applications hosted on Cloud Platform:
Check for Out Of Memory (OOM) errors on Cloud Platform with the following steps:
Locate the Out of memory errors section and review the instances where OOM errors have caused application restarts.
Data points that exceed 0 indicate the time when the Node.js application restarted because of OOM errors.
Monitor for a persistent rise in the memory usage that remains high even when the application is idle.
For example, the following image shows that the memory usage gradually increases to nearly 70% before being reset or terminated by the Linux system an because of an OOM event. The process then restarts and is terminated once more upon reaching the memory constraints.
The memory usage shown corresponds to the server's capacity. Therefore, it does not reach 100% because memory is still available in the system.
Application Performance Management (APM) tools such as New Relic provide significant assistance in diagnosing memory leaks. Node.js customers receive complimentary access to a New Relic instance for performance monitoring.
To diagnose memory leaks through APM tools:
Log in to New Relic and click APM & Services > Node VMs.
Select the VM instance of your application.
For example, select container_rootfs in the preceding image.
Examine metrics for the VM instance:
During the Garbage Collection (GC) phase, the application halts and does not process any requests. If the pause time is longer, it indicates that the application is dedicating more time to cleanup tasks. With a memory leak, the garbage collector does not reclaim memory effectively even after substantial GC activity. Significant and recurring spikes in GC pause time suggest a memory leak, which negatively affects the application's performance.
GC pause time refers to the period during which the runtime system is engaged in collecting garbage.
An increased frequency of GC pauses suggests more frequent garbage collections, which may point to a memory leak.
GC pause frequency refers to the occurrence count of garbage collector invocations within a given period.
In a well-functioning application, the garbage collector releases memory each time it activates. If the memory is not released at consistent intervals, it suggests a memory leak. In the following chart, the freed-up memory is gradually decreasing after every GC event.
Logging can be employed to monitor and prevent memory leaks. For example:
When substantial proofs of memory leaks exist, follow these instructions to address them.
Heap snapshots:
Analyze Heap snapshots:
Utilize profiling tools:
Identify common sources, such as:
Revise the code:
Enhance data structures:
Reorganize for improved memory management:
Conduct rigorous testing:
Mitigate future memory leaks:
With these instructions, you can systematically detect, diagnose, and rectify memory leaks within your Node.js application, and obtain enhanced stability and efficiency.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Mon Feb 24 2025 07:28:58 GMT+0000 (Coordinated Universal Time)