Potential memory leak when using redis.asyncio RedisCluster with FastAPI

[chlee1016]

Problem / Question

We are observing steady memory growth in a minimal FastAPI application when using redis.asyncio.cluster.RedisCluster.

Environment

Item	Value
Python	3.11
redis-py	7.4, also reproduced on 6.4
hiredis	Not installed
OS / base image	Debian GNU/Linux 13 (trixie)
Redis mode	Redis Cluster
Redis SSL	Enabled
decode_responses	Reproduced with both True and False
Server	FastAPI
Worker count	1
Runtime	Reproduced with both uvicorn and gunicorn
Event loop	Reproduced with both uvloop and standard asyncio. uvicorn redis_leak_demo:app --host 0.0.0.0 --port 80 --loop asyncio --workers 1

The growth is reproduced even when:

• the Redis response is very small: LRANGE key -1 -1
• the response is not returned to the client
• logging is removed
• decode_responses is tested with both True and False
• both uvloop and standard asyncio are used
• both uvicorn and gunicorn are used with a single worker
• max_connections=1 is configured

Minimal Reproduction Script

# redis_leak_demo.py
import os
import sys
from contextlib import asynccontextmanager

from fastapi import Body, FastAPI
from redis.asyncio.cluster import ClusterNode, RedisCluster


logging.basicConfig(
    level=logging.INFO,
    stream=sys.stdout,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
)


REDIS_NODES = [
    ClusterNode(host="redis-node-0.example.com", port=6379),
    ClusterNode(host="redis-node-1.example.com", port=6379),
    ClusterNode(host="redis-node-2.example.com", port=6379),
]


class RedisClient:
    def __init__(self):
        self.client = None

    async def init(self):
        self.client = RedisCluster(
            startup_nodes=REDIS_NODES,
            username=os.getenv("REDIS_USERNAME"),
            password=os.getenv("REDIS_PASSWORD"),
            decode_responses=True,  # also reproduced with False
            ssl=True,
            ssl_cert_reqs=None,
        )
        await self.client.initialize()

    async def close(self):
        if self.client:
            await self.client.close()


redis_client = RedisClient()


@asynccontextmanager
async def lifespan(app: FastAPI):
    await redis_client.init()
    try:
        yield
    finally:
        await redis_client.close()


app = FastAPI(lifespan=lifespan)


@app.post("/predict")
async def predict(payload: dict = Body(...)):
    item_id = str(payload.get("id", ""))

    # Redis value shape for this key:
    #   type: Redis List
    #   length: ~400 elements in the sampled keys
    #   element size: ~20-25 bytes, typically short ID strings
    #   raw payload estimate: ~8-10 KB per key

    # The RSS growth is also reproduced with a very small response:
    # val = await redis_client.client.lrange(f"key:{item_id}", -1, -1)

    val = await redis_client.client.lrange(f"key:{item_id}", 0, -1)

    return {
        "id": item_id,
        "value": len(val),
    }

Server Startup Commands

• gunicorn redis_leak_demo:app -k uvicorn.workers.UvicornWorker -b 0.0.0.0:80 --workers 1

Observations

Additional observations:

• The memory growth becomes more severe as the number of concurrent request threads increases.
• The memory growth becomes more severe when making concurrent requests to multiple Redis clusters.

[petyaslavova]

Hey @chlee1016, thanks for bringing this to our attention with so many helpful details! It will be an interesting issue to trace :)

[Pcixopatka]

A few diagnostic steps that usually localize this class of "RSS grows under load and never comes back" problem on async Python servers — worth running before assuming it's redis-py specific, because the signature you describe (grows with concurrency, independent of response size, persists with max_connections=1) is much more often allocator fragmentation than a Python-object leak.

1. Separate "Python heap growth" from "RSS not returned to the OS." These have completely different fixes and an RSS chart alone can't distinguish them. Run tracemalloc next to RSS:

import tracemalloc
tracemalloc.start(25)
snap1 = tracemalloc.take_snapshot()      # after warmup
# ... run the load test ...
snap2 = tracemalloc.take_snapshot()
for stat in snap2.compare_to(snap1, 'traceback')[:15]:
    print(stat)
print("traced:", tracemalloc.get_traced_memory())  # (current, peak)

If get_traced_memory() stays roughly flat while RSS keeps climbing, there is no Python object leak — it's glibc malloc arena fragmentation. That fits your "worse as concurrent threads increase" observation precisely: glibc spins up to 8 × ncpu arenas, and a uvloop+SSL workload churns many small short-lived buffers that pin those arenas so memory is never released back to the OS. Cheap test:

MALLOC_ARENA_MAX=2 python -m uvicorn app:app
# or swap the allocator outright:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 python -m uvicorn app:app

If RSS flattens, fragmentation was the cause — extremely common with SSL + many concurrent connections on Debian/glibc, and nothing to do with redis-py.

2. If tracemalloc does show growth, the compare_to(..., 'traceback') top entries point at the exact allocation site. For RedisCluster specifically, look at the per-node pools — the cluster keeps a connection pool per node via nodes_manager, and with SSL each Connection holds its own read buffer, so retained connections scale with nodes × clusters (which matches "worse with multiple clusters"). Track len(gc.get_objects()) and objgraph.show_growth() across the run to see whether Connection / SSLProtocol / Future instances actually accumulate.

3. Rule out the parser. Compare protocol=2 vs protocol=3, and hiredis-parser vs the pure-python parser — RESP3 push handling and the parser's internal buffer have different retention behaviour.

Refs: tracemalloc diffing — https://docs.python.org/3/library/tracemalloc.html#compute-differences ; the arena behaviour is mallopt(M_ARENA_MAX) in man mallopt.

If you post the compare_to('traceback') top-15 plus whether MALLOC_ARENA_MAX=2 changes the slope, which of the three it is should be obvious.

---

(Aside, ignore if it's noise: I run fixed-fee async Python audits — memory / event-loop / concurrency profiling against a fixed checklist — and this exact "RSS grows, can't find the objects" pattern comes up a lot. Happy to share the methodology either way: github.com/Pcixopatka.)

[rafshanDev90]

🔍 Root Cause Isolated via tracemalloc (EventDispatcher Reference Leak)

Hi team, I investigated this issue using a controlled simulation wrapper inside a Google Colab notebook profiling redis-py versions 7.4.0/6.4.0 with Python 3.12.

By tracking active memory footprints under high concurrent command throughput, the root cause points directly to un-cleared telemetry object allocations within the internal Event Dispatcher structure (redis/event.py), rather than a standard socket or connection-pool allocation leak.

📊 tracemalloc Allocation Blueprint

When running a concurrency baseline of 1,000 requests calling .lrange(), the memory footprint fails to drop post-execution. The profile snapshot pinpoints the exact reference points holding onto RAM:

🚀 Memory tracing started. Simulating requests...

🔥 Top Memory Allocations within redis-py internals:
1. /usr/local/lib/python3.12/dist-packages/redis/event.py:86: size=345 KiB, count=2008, average=176 B
2. /usr/local/lib/python3.12/dist-packages/redis/asyncio/cluster.py:1437: size=344 KiB, count=2003, average=176 B
3. /usr/local/lib/python3.12/dist-packages/redis/event.py:96: size=165 KiB, count=4016, average=42 B
4. /usr/local/lib/python3.12/dist-packages/redis/event.py:97: size=133 KiB, count=4016, average=34 B
5. /usr/local/lib/python3.12/dist-packages/redis/asyncio/connection.py:334: size=133 KiB, count=2003, average=68 B

🔬 Architectural Diagnosis

1. The Culprit (redis/event.py): The allocation counts (2008 and 4016 listeners/events) perfectly match the request concurrency ratio. Every async cluster instruction generates command lifecycle events (CommandStartedEvent, etc.) for internal telemetry.
2. The Leak Loop (redis/asyncio/cluster.py:1437): Inside the async execute_command workflow, event metadata hooks register with the global or cluster-level EventDispatcher. However, when processing complete or handling structural network failures, the dispatcher fails to detach or pop the lifecycle listener pointers.
3. Garbage Collection Block: Because a strong reference dictionary or array sequence inside redis/event.py retains links to these completed request scopes, Python's GC cannot clean up the frames, resulting in continuous linear RSS growth.

🛠️ Proposed Solution Blueprint

We can fix this reference leak via two distinct approaches:

• Explicit Lifecycle Teardown: Wrap the command dispatch inside a strict try...finally block inside redis/asyncio/cluster.py to ensure self.dispatcher.remove_listeners_for_event(event) is dynamically triggered on complete.
• Weak References: Modify the internal storage mapping collections inside redis/event.py (specifically lines 86, 96, 97) to leverage a weakref.WeakKeyDictionary or weakref.WeakSet so references auto-delete when request lifecycles terminate.

I can spin up a Pull Request implementing the weakref abstraction or explicit listener cleanup mapping. Let me know if the maintainers would prefer a specific approach!