NodeJs Memory leakage

Due to memory leakage in Node. javascript is very common. It may not be particularly sensitive to its memory leakage when using javascript in a browser, but you have to consider these issues when running as a server language. The previous Chance was that when react was rendered on the server, it was NODE_ENV! = Production will cause memory leakage. Specific issues: https://github.com/facebook/react/issues/7406. With the widespread use of technologies such as node and react, node memory leaks and other issues should be paid attention. Why is node prone to memory leakage and how to troubleshoot it? The following is a brief introduction and example.

First, node is based on the v8 engine, and its memory management method is consistent with that of v8. The following describes the memory special effects of v8.

V8 memory limit

Based on V8, node allocates and manages js objects through V8. V8 has limits on memory usage (the 64-Bit Memory of the old generation is about 1.4 GB, the 32-bit system is about 0.7 GB, And the 64-Bit Memory of the new generation is about 32 MB, about 16 MB in 32 systems ). Under such restrictions, large memory objects cannot be operated. If you accidentally touch this boundary, the process will exit.

Cause: V8 blocks the JavaScript Application logic when performing garbage collection until the garbage collection ends and re-executes the JavaScript Application logic, this behavior is called stop-the-world ). If the heap memory of V8 is 1.5 GB, it takes more than 50 ms for V8 to perform a small garbage collection. It takes more than 1 second to perform a non-incremental garbage collection.

Use node -- max-old-space-size = xxx (unit: MB), node -- max-new-space-size = xxx (unit: KB) set the new generation memory and old generation memory to crack the default memory limit.

V8 Heap Structure

The V8 heap is not only composed of the old generation and the new generation, but can be divided into several different regions:

New Generation memory zone: Most objects are allocated here. This zone is small but garbage return is particularly frequent.

Old Generation pointer area: belongs to the old generation, which contains most objects that may point to other objects. Most objects promoted from the new generation will be moved here.

Old Generation data zone: belongs to the old generation. Only the original data objects are saved here. These objects do not point to other objects.

Large Object area: stores objects larger than other areas. Each object has its own memory, and garbage collection does not move large objects.

Code area: the code object, that is, the object containing the JIT command, will be allocated here. Unique memory zone with execution permission

Cell, Attribute Cell, and Map: stores Cell, Attribute Cell, and Map. Each region stores elements of the same size, with a simple structure.

GC collection type

Incremental GC

Indicates whether the Garbage Collector collects (increases) the garbage while scanning the memory space and clears the garbage at the end of the scan cycle.

Non-incremental GC

When a non-incremental garbage collector is used, the collected garbage is cleared.

The garbage collector only recycles New Generation memory areas, old generation pointer areas, and old generation data areas. The object first enters the new generation memory that occupies less space. Most objects will soon become invalid, and non-incremental GC directly recycles these small amounts of memory. If some objects cannot be recycled for a period of time, they are in the old generation memory zone. Incremental GC is not frequently executed in this region and takes a long time.

When will it cause memory leakage?

Memory leakage

Memory leakage

Cache

Delayed queue consumption

Scope not released

The Node memory is mainly allocated by V8 and by Node. Most of V8's garbage collection restrictions are V8's heap memory. Main causes of Memory leakage: 1. cache; 2. Delayed queue consumption; 3. Unreleased Scope

Memory leakage analysis

View V8 memory usage (unit: byte)

process.memoryUsage();  {    ress: 47038464,     heapTotal: 34264656,     heapUsed: 2052866   }

Ress: resident memory of a process

HeapTotal, heapUsed: V8 heap memory information

View system memory usage (unit: byte)

OS. totalmem ()
OS. freemem ()

Returns the total system memory and idle memory.

View garbage collection logs

Node -- trace_gc-e "var a = []; for (var I = 0; I <1000000; I ++) {. push (new Array (100);} "> gc. log // output the garbage collection log

Node -- prof // output the performance log for node execution. Use a windows-tick.processor to view.

Analysis and monitoring tools

V8-profiler takes snapshots of v8 heap memory and analyzes cpu
Node-heapdump captures snapshots of the v8 heap memory.
Node-mtrace analysis stack usage
Node-memwatch listens for garbage collection

Node-memwatch

memwatch.on('stats',function(info){  console.log(info)})memwatch.on('leak',function(info){  console.log(info)})

Stats event: a stats event is triggered every time the whole heap garbage collection is performed. This event will pass the memory statistics.

{"Num_full_gc": 17, // number of full-stack garbage collection times "num_inc_gc": 8, // number of incremental garbage collection times "heap_compactions": 8, // sort the "estimated_base": 2592568, // estimated base "current_base": 2592568, // current base "min": 2499912, // min "max": 2592568, // max "usage_trend": 0 // usage trend}

Observe num_full_gc and num_inc_gc to reflect garbage collection.

Leak event: if the memory is still not released after 5 consecutive garbage collection times, the memory leakage occurs. This will trigger a leak event.

{ start: Fri, 29 Jun 2012 14:12:13 GMT,end: Fri, 29 Jun 2012 14:12:33 GMT,growth: 67984,reason: 'heap growth over 5 consecutive GCs (20s) - 11.67 mb/hr'}

Heap Diffing Heap memory comparison check memory overflow code.
The following example demonstrates how to locate memory leaks:

First, we create an example that causes memory leakage:

//app.jsvar app = require('express')();var http = require('http').Server(app);var heapdump = require('heapdump'); var leakobjs = [];function LeakClass(){  this.x = 1;} app.get('/', function(req, res){  console.log('get /');  for(var i = 0; i < 1000; i++){    leakobjs.push(new LeakClass());  }  res.send('Hello world');}); setInterval(function(){  heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot');}, 3000); http.listen(3000, function(){  console.log('listening on port 3000');});

Here we simulate Memory leakage by setting an increasing array that does not return to the recycled array.

The heap-dump module is used to regularly Record Memory snapshots, and chrome Developer Tools profiles are used to import snapshots for comparative analysis.

We can see that after accessing localhost: 3000 in the browser and refreshing it multiple times, the snapshot size keeps increasing and does not decrease even if no request is made, indicating that the snapshot has been leaked.

Beware of misjudgment. The short memory usage peak performance is like memory leakage. If your app suddenly occupies a large amount of CPU and memory, the processing time may span several garbage collection cycles, and memwatch may misjudge it as Memory leakage. However, in this case, once your app uses these resources, the memory consumption will be reduced back to the normal level. Therefore, you must note that the memory leakage is continuously reported, and you can ignore one or two sudden alarms.

For more details about node. js Memory leakage, refer to PHP Chinese network!