Severe memory regression in the supervisor process when workers > 1 (0.47.0+)

[mehdiboubnan]

What I'm seeing

After upgrading uvicorn 0.46.0 → 0.47.0+ on a FastAPI app running under Kubernetes with --workers 2, the parent (supervisor) process holds ~500 MB of RSS that it never serves with.
Downgrading to 0.46.0 immediately fixes it.

Setup

• Python 3.13.13 (slim container)
• uvicorn 0.49.0 (also reproduced on 0.47.0 and 0.48.0; 0.46.0 is fine)
• FastAPI app with ~25 routers — large import graph
• Kubernetes pod, UVICORN_WORKERS=2, no --reload
• Multiprocessing default (spawn on Linux for Python 3.14-track; uvicorn also forces spawn explicitly via uvicorn/_subprocess.py)

Numbers (py-spy + /proc inside the pod)

PID	Role	RSS
1	supervisor (idle in threading.Event.wait)	499 MB
24	worker	531 MB
25	worker	548 MB

py-spy dump --pid 1 shows the supervisor parked in Multiprocess.run → should_exit.wait(0.5). It doesn't handle requests, yet it holds nearly as much memory as a worker.

Root cause (what I believe is happening)

#2919 (b499bc4, released 0.47.0) added an eager config.load_app() in uvicorn.run() so the parent imports the ASGI app before constructing Server. The motivations were good (fail-fast on bad app paths, sidestep the asyncio-in-module-body crash from #941).

But:

• uvicorn's own get_subprocess forces multiprocessing.get_context("spawn").
• With spawn, workers get a fresh interpreter, they do not inherit the parent's sys.modules.
• The supervisor never serves traffic, it only spawns and restarts workers.

Net effect: every module imported by load_app() in the parent is pure resident-memory overhead for the lifetime of the server, never inherited, never used. For non-trivial apps it adds up to hundreds of MB.

Why I think it's worth fixing

This silently regressed memory for anyone running uvicorn with workers > 1 and a non-trivial app. The HPA in our cluster started
scaling pods more aggressively because the per-pod baseline jumped. The CodSpeed benchmark added in the same PR (#2919) used a trivial app, so it couldn't catch this.

Possible fix (happy to draft a PR if maintainers agree)

Only execute the app body in the parent when the parent is the worker (single process, no reload). For workers > 1 or --reload, validate the import string via importlib.util.find_spec (which doesn't execute the module body). That keeps the fail-fast property for missing modules and still avoids the asyncio-in-module-body crash for the single-process path, while making the supervisor cheap again.

Note: find_spec still imports the target's parent packages, so apps whose top-level __init__.py is heavy will see some residual supervisor RSS. For most apps the parent __init__.py is empty or near-empty; the patch is a strict improvement even when it isn't.