-
Notifications
You must be signed in to change notification settings - Fork 602
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
WebSocketConnection object possible memory leak #105
Comments
Do the objects end up disappearing after a second or two, or do the just kinda chill around with a permanent |
It's likely that the garbage collection hasn't kicked in yet. A more thorough way to test would be to continually connect and disconnect while watching the memory consumption. You should see a sawtooth pattern on the graph as memory is allocated and then freed once in a while by the garbage collector. Just doing 100 and then sampling afterward will not yield accurate results. Brian Sent from my iPhone
|
@theturtle32 That's what I was assuming would happen 👍 |
I believe that the heapdump plugin manually runs gc before creating a dump file. To be sure, I've also exposed the gc and run it frequently during dump retrievals. @chrisabrams We're currently running tests on it just now but there appears to be a few WebSocketConnection objects remaining with state:closed and they never appear to be cleaned up. I'll keep you informed on how our tests go as we're looking into whats possibly causing it. @theturtle32 I'm not sure if the built xor file is possibly causing it as when using the native js appears to clean up a few and the removal of the deprecated "webSocketVersion" properties seems to help also. We're also looking into native binds and listeners to see if its maybe a timing issue but nothing is for certain as of yet. |
@johnbrady6 Thanks for writing this up; I hope y'all are able to find what is causing these sockets to not be cleaned up :) |
Just a quick update. After finding this blog post http://www.tuicool.com/articles/yUR3q2 we began to look into slab buffers. After adding this line
it made a huge difference to our overall memory consumption as we have went from being able to handle from around 5000 concurrent WS connections to double that value per 2gb flavour servers. It doesn't really solve the leaking socket connection issue but thought it might be of some use to other WebSocket-Node library users. |
@johnbrady6 I've tried the test code you posted, and found some flaws and bugs with it. I've modified it and split it into a separate client and server process, and found that there doesn't seem to be any leak in WebSocket-Node (at least not with the latest modifications and enhancements on master.) I'm going to go ahead and close this. Once I release 1.0.9, go ahead and check again and let me know if this issue persists for you. I'll be adding my test server/client into the /test directory shortly. |
Hi, I don't know if anyone else has noticed this problem but there seems to be an issue with WebSocketConnection object not being cleaned up after the client connection has closed and gc has ran. Using the "memwatch" and "heapdump" plugins for node I have discovered when connecting 100 clients and then disconnecting 100 it appears that there are about 70 odd "state:closed" WebSocketConnection objects still lingering about. This was found using the example ws server code. As you can imagine after writing a script to repeat these steps over a period of a time these objects build up quite a bit of memory and are never released. If anyone has any recommendations or any insight on this issue it would be greatly appreciated. Thanks.
The text was updated successfully, but these errors were encountered: