-
Notifications
You must be signed in to change notification settings - Fork 534
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
memory from transport buffer not freed after connection_lost #548
Comments
i compiled from master with debug, and recorded the debug info (printing in protocol.connection_lost()) after a few runs (you can tell from the closed handles, that I'm not posting each one I capture). I do see the resident memory going down from 2gb to 1gb, but I don't know if that's just me swapping, or actually freeing up addressspace. virtual memory doesn't seem to be going down.
|
fwiw, running this after the transport is closed down seems to trigger a cleanup import ctypes
def malloc_trim():
ctypes.CDLL("libc.so.6").malloc_trim(0) as a workaround, I'm planning on firing a call to malloc_trim run a few seconds after connection_lost. at least until I get the buffer pause protocol implemented, I don't think there's an obvious bug to fix here, but who knows. |
PYTHONASYNCIODEBUG
in env?: yes, with PYTHONASYNCIODEBUG=1If I flood transport.write() and then close the connection (e.g. having the client telnet session stop) the memory stays resident.
Under stock asyncio, the memory immediately is released.
To reproduce,
This test script is a malloc bomb, so make sure you watch memory closely or you will consume all the memory on your machine
The text was updated successfully, but these errors were encountered: