Moving from Node to Bun spikes container CPU and memory usage until it crashes

[rbilgil]

I'm working on a branch to move from node to bun as our runtime. The docker container builds successfully, and on the surface the service seems to run without any errors. However, we're seeing very high memory & CPU usage after deploying the service onto GKE, which quickly leads to a service restart. No errors are being emitted, and the service seems responsive when it's running.

Services use about ~500MB of memory when running on node, but the memory quickly spikes to the container limit of ~1.2GB when running on bun.

Note: We have been using bun to run these same services locally on MacOS for over a year without any issues.

I've attached a screenshot of our CPU / Memory usage during the bun deployment. The only thing that changed in that time is two lines in the Dockerfile, image also attached.

Note that the image shows us running CMD [ "bun", "--max-old-space-size=4096", "--enable-source-maps", "./index.js"], I removed the source maps and max-old-space-size args in one test and it didn't fix the issue.

More context about our setup

• We build a single JS file using ncc for each service
• Service is built as a docker container and deployed onto GKE
• I tried the deployment both with the oven/bun:alpine image and also our usual node:alpine image with bun installed separately. No difference.
• bun version used: 1.2.2 (I also tried 1.2.4 but I get a segfault on startup)

At this point this is the only reason we can't fully migrate to bun, so any insight would be appreciated.

[nicklvsa]

I can confirm that I am also seeing very similar behavior running a node/express server using the Bun runtime. The node service in question generally sees around ~80MB of memory usage and very little cpu usage (<1%) but when using the Bun runtime and after a few seconds of load, the service spikes immediately to ~100% cpu and memory utilization, causing a SIGKILL signal to the task from our orchestrator (AWS ECS).

If I test the service locally or deploy it and run a few requests against it, everything seems to function correctly.

Our setup summary

• Node / express server
• Docker image running on AWS ECS / Fargate
• Using the oven/bun:alpine image
• Bun version: latest (v1.2.4)
• Using the new Bun S3 client, but have tried without it and still see the same issue.

I've also tried the slim version of the base Bun image along with v1.2.4, v1.2.2, v1.2.0, and v1.1.45 but got the same result with these combinations.

[cirospaciari]

@rbilgil @nicklvsa can you provide some more informations about the dependencies? package.json and/or version of relevant packages (express, prisma, db drivers etc)

[cirospaciari]

Investigating memory usage and cpu usage when using docker and prisma with sqlite and postgresql, with bun and node.

When running Both in node and bun using prisma with sqlite and with postgresql, the memory usage is similar.
I found that memory increases in both environments even calling gc manually.

I'm using the following versions:

• node v23.9.0
• bun v1.2.5-canary.47+078318f33
• prisma v6.4.1

CPU spikes at 80% and memory usage started in 48MB and reached 120MB after 3 minutes.
A constant increase in memory usage is observed when quering the database in both runtimes.
Node uses a little more memory than bun (bun used 113MB and node used 120MB).

Bun seems to keep stable memory in continuous queries when using BUN_JSC_gcMaxHeapSize=52428800

...
[1094.45ms] listUsers
memory usage 113
memory usage 113
[1037.05ms] listUsers
memory usage 113
memory usage 113
[1040.36ms] listUsers
memory usage 113
memory usage 113
[1049.12ms] listUsers
memory usage 113
memory usage 113
[1038.18ms] listUsers
memory usage 113
memory usage 113
[1040.09ms] listUsers
memory usage 113
memory usage 113
[1022.39ms] listUsers
memory usage 113
memory usage 113
[1023.52ms] listUsers
memory usage 113
memory usage 113
[1058.88ms] listUsers
memory usage 113
memory usage 113
[1069.89ms] listUsers
memory usage 113
memory usage 113
[1082.55ms] listUsers

CPU usage goes down after the first query, and only goes up when the query is repeated, but about the same usage as node.

My guess is that probably the problem can be another package, or just another scenario, will keep investigating the spikes in CPU usage.

[nicklvsa]

Hey @cirospaciari 👋, with my example, we are running a relatively simple express server via node 22. Our current notable public dependencies include:

• express@4.21.2
• memjs@1.3.1
• morgan@1.10.0
• aws-sdk
  • client-dynamodb@3.758.0
  • client-s3@3.758.0

We do also have some internally developed node packages. I was planning on attempting to slowly strip out any non-essential packages for testing to see if I could narrow down a potentially incompatible package, but I have not had to time to try that out yet. Maybe something to try here is to stand up a very basic express server with an endpoint or two and see if the memory+cpu utilization issue can be recreated. I can plan on trying this out when I have some time later this week.

[DonIsaac]

@rbilgil can you try setting the BUN_RUNTIME_TRANSPILER_CACHE_PATH environment variable to 0? We do this in our Docker images to reduce memory, but it looks like you aren't using it as a base path.

Edit: note that Bun does not respect --max-old-space-size

[nicklvsa]

👋 Following up here - I tested a couple of levels of simplification to the express server that we're running (all the way to a simple health check endpoint) and I am still seeing this memory issue. I have an interesting memory graph that shows the service sitting idle over a few days (with only the AWS ALB health checkers hitting the stack) with the most recent drop in memory being the most recent deployment I performed against the service.

It seems like other folks have seen similar patterns after exploring some other open issues (#4796). I haven't tried using the v8 heap snapshot api in Bun yet, but I wonder if that is something to try out here.

[Jarred-Sumner]

We are very actively working on reducing memory usage. I'm sorry we haven't fixed this yet.

[sculpt0r]

More complicated app based on expressJS on prod environment:

Slowly, but noticeable memory increase. I'm not sure if you already found 'something' or should I actively dig in my app to find what can cause such increase?

Exactly the same logic run with "much" higher traffic and node did not cause any increase of memory usage 🤔

[evsar3]

Same thing here using AWS ECS with Fargate:

This is a 12 hour graph

A couple useful info:

• This service is a SQS consumer
• This service uses oven/bun:latest base image
• This service is written in TypeScript and it is not compiled to JS. (This is the reason for the migration from Node.js in the first place; be able to run plain TS without the build step.)
• This is only one of a numerous services that is experiencing this behavior

[necmettindev]

I am experiencing the same problem

[Jarred-Sumner]

This PR changes JavaScriptCore's garbage collector heuristic for deciding whether or not to schedule a collection to be closer to what Node/V8 does. Microbenchmarks show a positive impact in scenarios that are likely similar to what is going on in this issue (quick burst of allocations blocking the event loop from idling and running timer-based GC). It's not ready yet - but I wanted to give some kind of update on this issue and show that we do care.

[ayZagen]

Hey @Jarred-Sumner, thanks for r your great work.
Is there any workaround until PR merged?

Does running Bun.gc() manually within a interval helps?

EDIT: I tried running Bun.gc() and Bun.gc(true) with 60s intervals. It didn't help at all. After load test finishes the memory is not released at all.