-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
High memory usage / large websocket buffer per client remains in memory after message is sent #3367
Comments
I've narrowed the problem down to two buffers:
These buffers each use Unfortunately, this means that once a I verified that if I Since the default behavior is to reuse existing allocations, i'm hesitant to actually It does seem somewhat unfortunate that these buffers are needed at all when it seems that, at least for the http encoder, the actual message contents are not modified at all, and are simply copied verbatim. The ws encoder sometimes copies verbatim although sometimes there is a 4 byte mask applied at the start. I don't know if I'd be confident enough to try to eliminate these extra buffers myself, though. I'd be interested to hear @robjtede 's thoughts on potential solutions here |
Issue: the websocket buffer per client will remain in memory and potentially continue expanding until stopping/closing the connection. This becames a major memory usage issue when sending a large amount of data to client(s).
Related to #3198 and #1967
I would expect the in-memory buffer to flush after a message is sent to a client (please correct me if I'm mistaken with the expectation).
Example below creates a websocket connection, connect to it and send a message "[x]M" (i.e. 5M or 10M) to generate a client message of x million random characters.
Memory starts around 4MB in the example video. Then the memory jumps to expand the in-memory buffer per client to accomodate the message size, but doesn't flush after being sent.
example.webm
Edit: updated example along with video.
rustc -V
):rustc 1.80.0-nightly (6e1d94708 2024-05-10)
4.5.1
The text was updated successfully, but these errors were encountered: