Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Queued buffers seemingly not cleaned up in closed sockets #2771

Closed
Euregan opened this issue Jun 12, 2020 · 3 comments
Closed

Queued buffers seemingly not cleaned up in closed sockets #2771

Euregan opened this issue Jun 12, 2020 · 3 comments

Comments

@Euregan
Copy link

Euregan commented Jun 12, 2020

  • Node.js Version: 12.9.1
  • OS: Debian 10

We have a websocket server that seems to be leaking RSS, quite like in nodejs/node#4779. I also tried the fixes in #1518, to no avail. For around 500 sockets at the same time (Very short lived, a few seconds at most usually), we can go to up to 5G in RSS, while the heap used stays at around 800M. My observations are pretty much the same as in nodejs/node#4779.

Observations

  • Slow clients (clients receiving data slower than server sends it) causes socket to increase their bufferSize
  • This typically increases the RSS of the node process
  • Upon disconnections of clients, we expect RSS to fall
  • The RSS grows to up to ~7G across 3 instances (The server has 8G), and then stays there until it gets killed for using too much when it goes a bit above.
  • The RSS is order of magnitude bigger than the actual Socket.bufferSize

Reproduction Steps

Test cases are in https://github.com/euregan/node-ws-slow-client-buffer-leak repository
Run server on a separate machine over the network
Run 200 clients for 30 seconds
RSS builds up.
Disconnects clients.
RSS stays built up

Graphs

Below are some graphs of the 3 instances. Sharp drops happen when the instance gets restarted either by pm2 or the system

Memory

Red is RSS
Yellow is Heap Total
Blue is Heap Used
0 - memory
1 - memory
2 - memory

Buffer size (bufferSize)

0 - buffer size
1 - buffer size
2 - buffer size

Websockets connected

0 - websockets
1 - websockets
2 - websockets

@bnoordhuis
Copy link
Member

Did you check with the inspector or node-heapdump that there's no leak in your program?

If heapdumps don't show anything but RSS peaks and won't come down, you might be running into (a variation on) nodejs/node#8871 or nodejs/node#33790 - tl;dr glibc memory fragmentation.

Switching to jemalloc can help, see the second issue.

@Euregan
Copy link
Author

Euregan commented Jun 16, 2020

Thanks for the quick response, heapdump were not showing anything indeed, since the heap total was never too high.
We switched to jemalloc yesterday, that seems to do the trick, though we can't figure out how to make it work with pm2. I'm closing the issue, but maybe a warning could be added to the doc? Should I make a PR?

@Euregan Euregan closed this as completed Jun 16, 2020
@eladnava
Copy link

@Euregan by running the following command, you can get pm2 and node to use jemalloc for memory allocation:

sudo -i
echo "/usr/lib/x86_64-linux-gnu/libjemalloc.so" >> /etc/ld.so.preload

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants