Open sergeysolovev opened 3 months ago
This is expected.
while (true) {
// ...
for (let i = 0; i < 10; i++) {
this.socket.send(LONG_STRING);
}
await this.delay(0);
}
The code is in a loop and filling up the write queue with lots of data very quickly.
The WebSocket
API by design does not provide async backpressure (WebSocketStream
fixes this) so its the caller that needs to check socket.bufferedAmount
.
Hey @littledivy yes I agree with your comment and even mentioned that in my original message. So yes I expect the memory to grow. What I don’t expect is that some (quite big part part) of the allocated memory stays there even after the connection is closed on the both sides.
I do not think this is a memory leak. This is V8 keeping around memory until the system needs it for other reasons - unless your program will eventually crash with an OOM, it is not a leak. V8 does not immediately release memory that JS is not currently using to the OS. It keeps it for a while in case JS needs to alloc in that memory space again. It's a relatively important performance optimization.
Version: Deno 1.45.5 OS: Amazon Linux or Ubuntu Linux
Steps: start the server and the client scripts, the server mem should quickly go up, stop the client script to disconnect. Because the server has disconnected the socket I expect the memory eventually to go down, but it keeps high for very long time.
Here is the log in my case:
Server: spam a client with numerous messages containing a long string. Notice I don’t check the socket’s
bufferedAmount
field.Client: very simple, just send a "subscribe” string and keep receiving the messages from the server