Per-Message Deflate Memory Leak

[yosiat]

sorry for not following the issue template, this way is easier to explain the issue, I will be happy to elaborate more

Description

In a production server after running a long time / mass-disconnection, I have noticed memory leak according to zlib & websockets.

This happens to all servers, but extremely happened to one of our servers which got mass-disconnect from 2.5k connected users to 50 connceted users. memory dump on this server showed:

• We have 87k instances of WebSocket class
• AsyncLimiter Queue have thousands of items

I managed to reproduce locally via:

• socket.io server (this my setup) with per-message deflate enabled
• connected with 200 users simultaneously and disconnected at once - memory stays the same, did manual garbage collection, wait for 2 for minutes, taking memory dump shows server still have WebSocket classes in memory.
• Connected again with 20 users and now I can't connect - not getting responses from the server. the server is stuck.

Root cause

Because of AsyncLimiter have 10 pending jobs that never finished, this happens as a result of a race - calling close on inflate/deflate won't close any further flushes.

Example:

inflate.write(...);
inflate.close(); // happened async
inflate.flush(() => /* won't be called */);

I made some patches in the code to make sure I call the callback, but I didn't like the solution of attaching a callback to inflate/deflate objects, since the object can handle multiple operations at the same time and we can have further racers.

In my opinion, we should decouple the inflate/deflate from per-message deflate and create a class which will have an internal queue and call to inflate/deflate, one cleanup it will flush the queue - this way we can the solve the issues I wrote above.

I can submit a pull request for the above approach.

Reproducible in:

• ws version: 6.4.1
• socket.io version: 2.2.0
• Node.js version(s): v10.15.3
• OS version(s): Mac (local) / Linux (production)

Memory dump screenshot

The picture above is a memory dump for the server which had mass-disconnect from 2.5k to 50 sockets:

• 88,992 instance of PerMessageDeflate
• 178,012 instances of WebSocket
• Array / Queue - is AsyncLimiter queue

[lpinca]

async-limiter was added in #1204 to work around this issue nodejs/node#8871, specifically nodejs/node#8871 (comment).

If I understand correctly the issue now is that it keeps stuff in its queue indefinitely due to never completing jobs (because flush() callback might never be called) right?

[lpinca]

See also discussion on #1369

[yosiat]

@lpinca hi!

I read both issues and the history behind it, but yes basically the issue that jobs are never completing and this way we don't clean up properly upon disconnection.

[lpinca]

Are you sure this happens with inflate streams and not deflate? Asking because due to how the WebSocket is closed, close() should not be called on the deflate stream until there is data to read.

For deflate streams instead close() can also be called while data is being compressed.

[yosiat]

@lpinca this happens on deflate, sorry

[lpinca]

Ok it makes sense and I can see why jobs might never complete. This also made things worse

ws/lib/permessage-deflate.js

Lines 424 to 432 in fa99173

	if (!this._deflate) {
	//
	// This `if` statement is only needed for Node.js < 10.0.0 because as of
	// commit https://github.com/nodejs/node/commit/5e3f5164, the flush
	// callback is no longer called if the deflate stream is closed while
	// data is being processed.
	//
	return;
	}

but reverting it would cause other problems. I'm not sure how to properly fix this.

[yosiat]

@lpinca in my tests the flush callback is never called after you call close, I suspected at this code but it wasn't relevant

[lpinca]

If you are using Node.js 10 it is expected, it was called before. Anyway we have to store the callback somewhere and call it when the final close() completes without actually calling this other callback

ws/lib/permessage-deflate.js

Line 315 in fa99173

callback(err, result);

if _deflate was nulled by the final close.

[lpinca]

Thank you for the report. If you want to try to fix it please do. I'm not sure when I can do it.

[yosiat]

@lpinca I have some fix currently and I don't like it.

Which is putting the callback in inflate as well, and on PerMessageDeflate#cleanup call those callbacks. but this is problematic IMO because we are settings callback on shared-resource.

A better fix IMO is to have a class which does deflate/inflate and have in its queue - data (to compress) and promise, this way we don't have a direct reference to WebSocket.

I'll play with this approach and update you

[lpinca]

Which is putting the callback in inflate as well, and on PerMessageDeflate#cleanup call those callbacks. but this is problematic IMO because we are settings callback on shared-resource.

It is not a big problem. There is one PerMessageDeflate instance per WebSocket and one inflate/deflate stream per PerMessageDeflate instance. Furthermore there can only be a single write/compress at time so we have to save/call only the latest callback.

[yosiat]

@lpinca how do you guarantee that you have single write at the time?

[lpinca]

It's done in https://github.com/websockets/ws/blob/master/lib/sender.js, we queue writes.

ws/lib/sender.js

Lines 266 to 267 in fa99173

	if (this._deflating) {
	this.enqueue([this.dispatch, buf, this._compress, opts, cb]);

[yosiat]

and what about reads (deflate) ?

[lpinca]

They should not have the issue described here because close() should never be called on inflate streams while data is being decompressed due to how the WebSocket is closed.