Memory leak?

[plucky gulch]

I deployed a Bun v.1.1.45 app written with Elysia, Drizzle (with postgres.js driver), S3 (@aws-sdk/client-s3), and Redis (ioredis). Upon deploying the app and leaving it running overnight, I noticed that throughout roughly 13 hours, the app went from using 145mb to 205mb of RAM. Seeing as I have 5 cron jobs running, I decided to see if the issue persisted in my dev environment without any requests of any kind being made and no cron jobs running. With heapStats().heapSize and an interval, it starts at 18.76mb and after several minutes, it's now 20.33mb, and again, no requests or cron jobs running.

Is this a Bun issue? I couldn't find any memory leaks being reported on any of the software I mentioned, but I wanted to inform about my stack in case anything's relevant.

Also, I deployed it on Render, so the 145mb and 205mb values aren't numbers gotten with heapStats().heapSize, meaning that they take into account the OS that's running and anything else the server is running alongside the Bun app

[plucky gulch]

I experimented for a bit and manage to reproduce it with just this code:

import { heapStats } from 'bun:jsc';

function formatHeapSize(heapSize: number) {
  const units = ['B', 'KB', 'MB', 'GB', 'TB'];
  let index = 0;

  // Convert bytes to the appropriate unit
  while (heapSize >= 1024 && index < units.length - 1) {
    heapSize /= 1024;
    index++;
  }

  // Format to 2 decimal places
  return `${heapSize.toFixed(2)} ${units[index]}`;
}
console.log(formatHeapSize(heapStats().heapSize));
setInterval(() => {
  console.log(formatHeapSize(heapStats().heapSize));
}, 10_000);

After leaving it running for a few minutes, it goes from 241.14kb to 425kb

Also, the Render server is running Linux (not sure what distro though) and I'm running Windows 11 locally for dev

[tight hound]

https://github.com/oven-sh/bun/issues/16488 see my comments on this issue. i'm quite confident there's no leak in this code, but there could be one affecting your actual production app

[tight hound]

i'm curious if running Bun.gc(true) occasionally makes your memory usage more consistent

if so then the problem is not a leak but just us not running the garbage collector enough

[plucky gulch]

Oh, alright. First time I've taken a look at memory usage in detail so I'm not knowledgeable on how things work on the low-level side of things

[plucky gulch]

So, running an interval like this?:

const app = new Elysia().listen(...);

setInterval(() => {
  Bun.gc(true);
}, 30_000)

console.log(`🦊 Elysia is running at ${app.server?.url.toString()}`);

[tight hound]

give it a shot

oh and

the other thing i'd do is log uptime and memory usage of only the bun process at an interval

that way you can make a graph and it's easier to tell whether memory is permanently increasing, or just fluctuating up and down

[plucky gulch]

Alright, thanks for the suggestions. I'll try using Bun.gc first

[plucky gulch]

The memory usage in my prod app seems to be stable now. I set an interval to run Bun.gc(true) every minute

[tight hound]

ok so you're probably seeing the issue that we don't run gc frequently enough

it's annoying though it's not technically a leak as the gc would eventually clean up that memory -- we just sometimes wait too long so more unused memory accumulates than there should be

i'm working on some changes in https://github.com/oven-sh/bun/pull/15557/ that should hopefully improve this somewhat

[plucky gulch]

Sounds good, thanks for the help 👍

[grand edge]

Just saw this, going to add the GC setInterval to my code and see if that helps me too

https://github.com/oven-sh/bun/issues/16703 won't a have a report on how running gc works until next week

[dapper bridge]

same

i got memory leak just with elysia

i spent the whole day rechecking my code to make sure and test with autocannon

it always goes up but dont go back down

[tight hound]

hm that's interesting that it changed in 1.2

[grand edge]

If you can reproduce get a file from this and attach to that issue:

console.log(heapStats());```

[hot timber]

how did you guys test your backend that there is a memory leak? please teach me how @plucky gulch

[plucky gulch]

The site where I deployed my app (Render) has a graph on how much memory the instance consumes, that's how I found out in prod. In dev, you can use setInterval and log the result of heapStats function from bun:jsc

[hot timber]

how can we handle to clean ?

[grand edge]

You can try running gc once in a while to see if that helps:

  Bun.gc(true);
}, 30_000)```

[tight hound]

the other point of running gc explicitly is it lets us tell whether high memory usage is due to a leak or due to not running GC enough

if memory still increases steadily even when you run GC more then that's a real leak

[grand edge]

I'll start running GC every 30 minutes tomorrow and see what that does

[plucky gulch]

I have an interval running every minute, I haven't experienced anything abnormal since. Very stable memory usage

[lilac pier]

running gc?

[grand edge]

GC helped me but I think there is still an issue, I'm trying to bisect

[plucky gulch]

Yes

[plucky gulch]

Might be worth opening a separate thread detailing any relevant packages

[tender canyon]

I'm experiencing a similar issue. memory usage goes up constantly until it's released again. have only started with deploying v1.2.0, so don't have a comparison with previous version

[grand edge]

It looks like issue I was having is probably fixed in the latest commits, so try again on canary or wait for 1.2.1 and try again. I'll be staying on 1.1 until 1.2.1 comes out

[timber moth]

I’m not 100% confident it’s fixed (no repro) but 80%:

• there was a case where we switched internal JSC bindings to create strings and we were incrementing a reference count one extra time
• there was a pre-existing bug where long request URLs in some cases were not decrementing their reference count
• the URL class in JS was not reporting memory usage of the strings inside to GC, so a large URL object could use lots of memory without the GC being aware of it leading to it taking longer to get collected