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:

• [email protected]
• [email protected]
• [email protected]
• aws-sdk
  • [email protected]
  • [email protected]

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 (https://github.com/oven-sh/bun/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.

[erik-Ak]

Can confirm, switched from node:20-slim to oven/bun:1.2.13-alpine.

With node:20-slim idle CPU usage of the container was ~0.001 With oven/bun:1.2.13-alpine idle CPU usage of the container is ~0.100.

For context, our setup

Node / ExpressJS server Running on Civo K8s clusters Container image oven/bun:1.2.13-alpine

P.D With oven/bun:1.2.13-alpine the docker container size dropped to ~300MB, whilst with node:20-slim it was ~970MB.

[dmythro]

Can confirm, switched from node:20-slim to oven/bun:1.2.13-alpine.

With node:20-slim idle CPU usage of the container was ~0.001 With oven/bun:1.2.13-alpine idle CPU usage of the container is ~0.100.

For context, our setup

Node / ExpressJS server Running on Civo K8s clusters Container image oven/bun:1.2.13-alpine

P.D With oven/bun:1.2.13-alpine the docker container size dropped to ~300MB, whilst with node:20-slim it was ~970MB.

Nice input, thanks. Did you try multi-stage standalone builds, or better — bun's standalone builds to binary? Curious to hear from someone with K8s if it makes the difference in performance.

[erik-Ak]

Can confirm, switched from node:20-slim to oven/bun:1.2.13-alpine. With node:20-slim idle CPU usage of the container was ~0.001 With oven/bun:1.2.13-alpine idle CPU usage of the container is ~0.100.

For context, our setup

Node / ExpressJS server Running on Civo K8s clusters Container image oven/bun:1.2.13-alpine P.D With oven/bun:1.2.13-alpine the docker container size dropped to ~300MB, whilst with node:20-slim it was ~970MB.

Nice input, thanks. Did you try multi-stage standalone builds, or better — bun's standalone builds to binary? Curious to hear from someone with K8s if it makes the difference in performance.

Вітаю пане)

Yes, tried everything, standalone, multi-stage...

Even the most simple js app just for the sake of testing. But nothing, it just keeps consuming high amount of CPU...

Seems like even the most lightweight bun images, (e.g alpine) still use high CPU...

[vriesr032]

I can also confirm, switched from node:22-bookworm-slim to oven/bun:1.2.13-slim. The memory usage seems allright but the CPU goes way up from 3mCPU to 113 mCPU:

[dmythro]

I can also confirm, switched from node:22-bookworm-slim to oven/bun:1.2.13-slim. The memory usage seems allright but the CPU goes way up from 3mCPU to 113 mCPU:

Wow, that looks huge!

[Nneji123]

@Jarred-Sumner I think this might be a problem down the line

[sanwalpride]

Found any soloution?

[nsmle]

any updates?

[likeon]

My project running bun with elysia experiences this, but not as dramatic as some other people have it in this thread. CPU and memory usage slowly creeps up over time, if pods lived for 2-3 days response time on endpoints that take 1-2ms under normal conditions reaches 20+ ms.

[dmythro]

My project running bun with elysia experiences this, but not as dramatic as some other people have it in this thread. CPU and memory usage slowly creeps up over time, if pods lived for 2-3 days response time on endpoints that take 1-2ms under normal conditions reaches 20+ ms.

Wow, it is a big difference relatively. Wondering why. I planned to move to Elysia as well my API. But if it's a slow leak, at least there's an option to restart the service nightly or something.

[jjpark78]

we also has same issue. so while coding and test use Bun, it is all-in-one very comprehensive, and build with node mode, running on node T_T

• nestjs + otel with node : 90-100 MB, stable
• with bun : from 150MB and keep increase.

[MilPredo]

i have weird issue, my bun + elysia server on an ec2 instance easily reaches 1GB memory usage in 7 minutes. but on my own PC, memory usage still grows from 150 mb, and increases by 2mb every 60 seconds. There are no active connections to my websocket or apis.

Update: I was able to resolve this by removing all the custom mongoose settings we used. Somehow our settings caused a memory leak. not sure if it's a bun issue or mongoose issue.

[gpaiva985]

any updates?

[dmythro]

any updates?

I shared this issue with devs of bun and Elysia, but didn't even get a reply so far.

[sculpt0r]

Seems like still in progress... Some issues was resolve like in Bun.spawn, but still not all of them. Waiting for 1.3 🤞

[krzkz94]

Can confirm am experiencing a memory creep even with the app being fully isolated and just returning a HTTP 200 from the /health endpoint (for the aws ALB)

[jerrygreen]

I had the slow leak too. Over night without any load: +500M in usage. Which is about 1M per minute leak. It seems the leak was somehow related to Vite+Bun – when I updated Vite from 5.4.11 to current lastest 7.1.2, seemingly it did solve the slow leak... Well, I'm not sure. I still see the megabytes adding, same 1M per minute. Only now they're cleared sometimes, so technically – no leak?

Next thing I noticed, it uses some little but nonetheless some CPU when idle, compared to Node which literally sits at 0.0% CPU when idle, – but this one seems to be fixed in recent update bun v1.2.20 – I can't wait when this update comes to nixpkgs registry so I can update to this bun version, too! (from bun v1.2.13)

Before that, I think I will sit at Node for a little more while. But I'm hyped.

[filipduch]

We are experiencing the same issue. The leak is around 45MB per hour. Takes almost 5 days to go from 6.2GB available memory to 0.8GB and then CPU goes 100% and stops responding to requests. We use Bun+Hono (1.2.20)