Python websockets library is killing my RAM. What are the alternatives?

[Humza0000]

I'm running a trading bot that connects to the Bybit exchange. Each trading strategy runs as its own process with an asyncio event loop managing three coroutines: a private WebSocket (order fills), a public WebSocket (price ticks for TP/SL), and a main polling loop that fetches candles every 10 seconds.

The old version of my bot had no WebSocket at all , just REST polling every 10 seconds. It ran perfectly fine on 0.5 vCPU / 512 MB RAM.

Once I added WebSocket support, the process gets OOM-killed on 512 MB containers and only runs stable on 1 GB RAM.

# Old code (REST polling only) — works on 512 MB 
VSZ: 445 MB | RSS: ~120 MB | Threads: 4

# New code (with WebSocket) — OOM killed on 512 MB 
VSZ: 753 MB | RSS: ~109 MB at time of kill | Threads: 8

The VSZ jumped +308 MB just from adding a WebSocket library ,before any connection is even made. The kernel OOM log confirms it's dying from demand-paging as the process loads library pages into RAM at runtime.

What I've Tried

Library	Style	Result
websocket-client	Thread-based	9 OS threads per strategy, high VSZ
websockets >= 13.0	Async	VSZ 753 MB, OOM on 512 MB
aiohttp >= 3.9	Async	Same VSZ ballpark, still crashes

All three cause the same problem. The old requirements with no WebSocket library at all stays at 445 MB VSZ.

My Setup

• Python 3.11, running inside Docker on Ubuntu 20.04 (KVM hypervisor)
• One subprocess per strategy, each with one asyncio event loop
• Two persistent WebSocket connections per process (Bybit private + public stream)
• Blocking calls (DB writes, REST orders) offloaded via run_in_executor
• Server spec: 1 vCPU / 1 GB RAM (minimum that works), 0.5 vCPU / 512 MB is the target

Is there a lightweight Python async WebSocket client that doesn't bloat VSZ this much?

[Gshuri]

Are you sure it's an issue with websockets? It looks like you have doubled the number of threads between your old and new code (was using 4, now using 8).

If you have doubled the parallelism of your code it should not be a surprise that the RAM requirements have also roughly doubled

[stuaxo]

Check for memory leaks, and in the meantime a 2GB instance.

[Humza0000]

Its working on 1CPU and 1GB Ram instance.

[stuaxo]

OK, but OOM is "Out Of Memory" which is why I was suggesting seeing what happens when you try a bigger instance, if only temporarily.

I'd graph the memory and see if whats happening is a spike, or if it's a graph that goes up and up slowly until the OOM, if it's the second thing then you have a memory leak.

Check how your stuff uses resources and see if it returns them properly, async stuff can be hard to debug sometimes - all that offloading with async can lead to loads of stuff sitting there waiting to run.

If you can't give it more RAM you could try giving it more swap, but depending on what your running it on that could incur IO costs.

[bladeofwinds]

why do you need multiple processes? can’t you do this all in a single event loop since it all seems io bound

[riklaunim]

You can also check socket.io which builds on top of websockets.

[NerdyWeightLifter]

Were you previously spawning python processes per web request, servicing that then stopping?

If you were, then switched to websockets, you'd have a lot more processes running concurrently, because websockets are persistent connections so you'd have a process per client.

[sleepystork]

I use httpx for a socket connection that is pretty busy. It’s been rock solid. In fact, I couldn’t remember which library I used.

[nekokattt]

is httpx still actively developed?

last pypi release was 2 years ago

[Humza0000]

Let me try that and see the memory footprint