Memory Leak and/or Sessions not Cleaned Up

[mixxen]

Describe the bug

We are using Marimo to provide a user interface dashboard for our users. The app has multiple tables, multiple forms, and a few Altair data visualizations. It also uses Polars to cache data for the application.

We've noticed that after a short period, Marimo consumes a huge amount of memory. After investigation, we found that every time we refresh the page, Marimo allocates more memory and consumes more CPU, eventually saturating the host resources and becoming extremely slow and unusable.

Below you can see Marimo's memory usage after refreshing the page 10 times. In this test, there is no data in the Polars data frames:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND 
1197755 root      20   0 3647480 659596 172288 S  83.5   1.0   0:47.85 marimo 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND 
1197755 root      20   0 5846168   2.2g 172376 S 115.9   3.6  14:12.20 marimo

Here is a Grafana view on our server over a couple of hours (just testing with a couple of users). The data in the Polars data frames is very minimal for this test:

Memory consumption spikes when someone hits the dashboard. After they exit, memory is not reclaimed, and over time, the app becomes noticeably slower.

We tried running Marimo like this:

marimo run src/ui/pages/main.py --host 0.0.0.0 --port 8000

uvicorn ui.app:make_app --factory --host 0.0.0.0 --port 8000 --timeout-keep-alive 300 --ws-ping-interval 1 --ws-ping-timeout 60 --timeout-graceful-shutdown 1

I've searched the documentation and issues for anything regarding session cleanup, etc. I did not find anything. We could use help to determine if this is a bug in Marimo or if we are doing something incorrectly on our end. Marimo is a pretty great idea; thank you in advance.

Environment

app-1  | {
app-1  |   "marimo": "0.10.17",
app-1  |   "OS": "Linux",
app-1  |   "OS Version": "6.8.0-1021-aws",
app-1  |   "Processor": "x86_64",
app-1  |   "Python Version": "3.10.16",
app-1  |   "Binaries": {
app-1  |     "Browser": "--",
app-1  |     "Node": "--"
app-1  |   },
app-1  |   "Dependencies": {
app-1  |     "click": "8.1.7",
app-1  |     "docutils": "0.21.2",
app-1  |     "itsdangerous": "2.2.0",
app-1  |     "jedi": "0.19.2",
app-1  |     "markdown": "3.7",
app-1  |     "narwhals": "1.13.5",
app-1  |     "packaging": "24.2",
app-1  |     "psutil": "6.1.0",
app-1  |     "pygments": "2.18.0",
app-1  |     "pymdown-extensions": "10.12",
app-1  |     "pyyaml": "6.0.2",
app-1  |     "ruff": "0.7.4",
app-1  |     "starlette": "0.41.2",
app-1  |     "tomlkit": "0.13.2",
app-1  |     "typing-extensions": "4.12.2",
app-1  |     "uvicorn": "0.32.0",
app-1  |     "websockets": "12.0"
app-1  |   },
app-1  |   "Optional Dependencies": {
app-1  |     "altair": "5.4.1",
app-1  |     "anywidget": "0.9.13",
app-1  |     "pandas": "2.2.3",
app-1  |     "pyarrow": "18.0.0"
app-1  |   },
app-1  |   "Experimental Flags": {}
app-1  | }

Code to reproduce

No response

[mscolnick]

Thanks for the issue, i have what could be a fix here (#3627), but haven't tested the memory is reclaimed. I will try to test manually on my end

[mscolnick]

@mixxen, we are still investigating. Could you try marimo run src/ui/pages/main.py --host 0.0.0.0 --port 8000 --session-ttl=0. The sessions should be cleaned up after 2 minutes, but either something is happening in those 2 minutes or the leak is somewhere else.

[mixxen]

Thanks for looking into this. I tried running Marimo with --session-ttl=0 and saw the same resource usage. I refreshed the page about 10 times and closed the window. Here are the usage stats 5 minutes after closing all windows:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND          
1509463 root      20   0 5661240   2.2g 191552 S  50.0   3.6   8:18.94 marimo

[mscolnick]

We have narrowed it down and have 2 fixes: #3634 and #3635

This should help significantly. The first with reclaiming memory and the second with random spikes in memory (although the second is more of a edge case you maybe didn't hit).

[schlich]

I'm having pretty severe memory leakage too... to the point i can't really use this on my machine until it's fixed.

It sounds like y'all are on the path to a fix but let me know if i can be of any debugging service.

attaching a bit from my dev logs just in case

marimo-logs.txt

edit: y'all are the fastest paced open source project out here fr fr

[mscolnick]

@schlich. is this in marimo run or edit? we have lots of fixes coming in both and will release them out today!

[schlich]

@schlich. is this in marimo run or edit? we have lots of fixes coming in both and will release them out today!

It was edit

[akshayka]

@schlich — is there anything else you can share?

• Were you running marimo edit (a notebook server) or marimo edit notebook.py (a single notebook)
• Did you have multiple notebooks open or just one?
• Had the notebook server been open for a long time (several days)?
• Do you have a notebook you can share that reproduces the issue?
• Are you fairly confident it was a leak, or could it have been a spike in memory consumption?

The changes we pushed likely won't fix a leak in edit mode, which is why I ask. Thanks!

[schlich]

I wish i could tell you more info, i'll do my best but i've been playing with enough configuration that it seems to have worked itself out.

• happened for both notebook server and individual notebooks several times
• i think it's possible i not only had multiple notebooks open, but maybe even multiple instance of the same notebook open (i've been messing around with Spaces on my mac and stuff gets hidden a lot).
• Notebook was definitely not running for that long. at the peak of the problem, the notebook couldnt even run small computations on small tables without crashing, even right after a reboot (autorun disabled). thus i don't think it was a memory spike.
• it's possible that hard disk space on my mac was low, since then i've run dust to do some cleanup

[mixxen]

Impressed at the agility of this team! I just tried the new version and it still exhibits the same issue. I ran my test, closed all windows, and left the server running overnight. When I got back, it was still consuming memory and CPU:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND 
2220875 root      20   0 6745812   3.4g 192340 S 110.9   5.4     12,51 marimo 

I'll try putting together a similar stressing UI to reproduce this issue for you to try.

[akshayka]

Thanks for trying, any kind of reproduction would be very much appreciated!

[mixxen]

I've tracked down the resource leak to this setting in .marimo.toml:

[runtime]
auto_reload = "lazy"

I initially created a toy app to reproduce the memory leak here, https://github.com/mixxen/marimo-stress, but I did not see a memory leak. So I went back to our original application and removed all components until there were none, and it still leaked memory. I traced it down to the auto_reload setting since my toy app did not initially have a .marimo.toml defined. Seems to leak memory faster with more imports.

Hope that helps.

[akshayka]

That's extremely helpful. I will investigate. Thank you!