If you're running heavy AI inference on a limited-RAM server, you've probably watched your containers die silently. When diagnosing these massive memory leaks, the culprit is often how you serve asynchronous Python.

Many teams default to Daphne for WebSockets and long-lived connections. But under the heavy memory pressure of streaming AI payloads, Daphne's single-process architecture becomes a severe bottleneck.

The Single Process Trap

Because Daphne is a single process, streaming massive AI payloads inevitably causes memory fragmentation. The process swells up, and crucially, often fails to release that RAM back to the OS when the connection closes.

Left unchecked, a single bloated process will eat all your host memory until the Linux OOM killer wakes up—often taking down your database alongside your app.

The Fix: A Managed Worker Pool

The most robust fix is migrating your ASGI interface to Gunicorn with Uvicorn workers. This shifts you from a monolithic process to a managed pool of isolated workers.

The real magic here is Gunicorn's max_requests parameter. By forcing workers to systematically recycle themselves after handling a set number of requests, you guarantee memory is reclaimed at the OS level:

gunicorn core.asgi:application -k uvicorn.workers.UvicornWorker --workers 4 --max-requests 1000 --max-requests-jitter 50

Defense in Depth

As a final safeguard, enforce hard memory limits (like mem_limit: 1G) in Docker.

If a Gunicorn worker somehow fails to recycle and starts bloating, Docker will kill and restart that specific container long before it threatens the host OS. When streaming resource-intensive AI, prioritizing total system uptime over the lifespan of a single HTTP worker is a trade-off you have to make.