zed-industries
Zed is leaking memory
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
I have upgraded to Zed 0.130.6 about yesterday and it's been running non stop since update.
I have installed some extensions, but other than that been just using Zed for its primary function - editing code.
Today macOS forced close citing Zed consuming over 62Gb of memory.
Environment
Zed: v0.130.6 (Zed) OS: macOS 14.3.0 Memory: 16 GiB Architecture: aarch64
If applicable, add mockups / screenshots to help explain present your vision of the feature
If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.
the log seems to be overwritten by the next zed launch already...
As a result, i've lost all open files projects state; the window that loaded had ENTIRE ssd drive added as a project (but old files from the project correctly opened); when i tried to re-add my project folder I had to remove the ENTIRE ssd from there first and thus I lost all the open files states, now it has a project I want in the sidebar but none of the previously open files are open anymore.
Recent projects look like this:
Hey! So, to be clear: what are the steps to reproduce? Open the whole harddrive as a folder in Zed? Or how did that happen?
This may be a dupe of:
- https://github.com/zed-industries/zed/issues/9744
Its hard to tell though, because we don't really know what is causing this.
No, I didn't do anything except have my project open.
The opening of the whole harddrive happened after I restarted Zed - it was unwanted, to say the least.
This may be a dupe of:
I was running 2 instances of Zed working between 2 repos with small codebases. Each repo has ~2k lines of code.
this part seems similar, I had a second instance running in the background, but I didn't use it actively.
Same for me.
But in my case try to reproduce this scenario:
- Open any large project which causes Zed to run node ts langguage server process, for example https://github.com/vuetifyjs/vuetify
- Check RAM usage top/htop
- Open a bunch of different files ts, tsx, vue,... - around 15-20
- Look for the memory usage
- Try to close all opened tabs
- RAM usage will be the same, without freeing up space
- You can continue and open 10 more files (different from previous)
- RAM usage will be the same or in some cases will increase
I had another case when I tried to open 3GB file, Zed handled it perfectly, but after closing and removing this file - memory usage was really huge, so I handled it by restarting editor.
I'm running latest stable release at this moment.
I see. Technically that's not a leak, I'd say, but more that MiMalloc (the allocator we use) is really aggressive about retaining memory. See this comment for more details: https://github.com/zed-industries/zed/pull/10321#issuecomment-2056763742
Makes me wonder whether we shouldn't switch from MiMalloc back to the default allocator that's less aggressive.
This may be a dupe of:
Its hard to tell though, because we don't really know what is causing this.
Part of this is definitely MiMalloc as discussed in other threads such as https://github.com/zed-industries/zed/pull/10321#issue-2233490156 .
There are probably a few memory leaks here and there (even the best written rust programs may have those...) and MiMalloc makes them worse.
I see. Technically that's not a leak, I'd say, but more that MiMalloc (the allocator we use) is really aggressive about retaining memory. See this comment for more details: #10321 (comment)
Makes me wonder whether we shouldn't switch from MiMalloc back to the default allocator that's less aggressive.
Hello, what steps should I take to suggest to revert back from MiMalloc?
The discussions about memory usage and retention, as well as the facf that MiMalloc does not play well with Instruments, suggests to me that it is a mistake to use it during development.
Zed (as in the company) can always use it to compile releases.
So, i tried re-running latest version of zed and seeing how memory usage changes over time.
Zed: v0.132.3 (Zed)
OS: macOS 14.3.0
Memory: 16 GiB
Architecture: aarch64
Ran in the morning, RAM was really nice: about 256Mb total. Started working on the project - single Zed window, single project, about 20 files edited in total. Memory usage grew to 2.5Gb. And kept growing as I jumped from file to file.
Restarted Zed. Started idle at about 256Mb RAM.
Started working on the same project: was about 393Mb of RAM taken, I just clicked around through 4 or 5 tabs with already open files and memory usage grew by 5Mb (398Mb now).
Came back to Zed from this browser window and it grew to 400Mb, then fell down to 398Mb again.
Clicked through some tabs, memory usage grew to 403Mb then fell to 397Mb.
Clicked some not-yet-open files and usage jumped to 425Mb then quickly shrank to 415Mb.
Pretty sure the OS does memory page compression behind the scenes quite aggressively, so the taken RAM for idle files will quickly be moved to the compressed area.
I will keep it running for some time.
So it keeps running, slowly leaking into the compressed memory:
After a day of doing almost nothing, it's at 555Mb RAM and grown into 389,5Mb compressed (from about 230Mb) - so it seems like memory is leaking all the time, slowly, never addressed again so the OS just moves it to the compressed part.
Couple days passed, I didn't have any chance to open the laptop and use Zed at all.
However, it had consumed a lot more compressed memory now - meaning there's still some mem leaking and being compressed by the OS into the idle memory:
So it keeps running, slowly leaking into the compressed memory:
After a day of doing almost nothing, it's at 555Mb RAM and grown into 389,5Mb compressed (from about 230Mb) - so it seems like memory is leaking all the time, slowly, never addressed again so the OS just moves it to the compressed part.
More than leaking it is MiMalloc that is very aggressive in not releasing the large chunks of memory (sometimes called arenas or pools) it then uses for carving the actual allocations out of them. In other words, once MiMalloc has gotten some memory from the system, it will likely not give it back for a LONG time, if at all. It is an ideal allocator for a computer game, not so sure for an editor, or a service. This also malkes it VERY difficult to do a proper analysis of memory leakagem since Instruments.app does not work well with MiMalloc.
@mrnugget and @mikayla-maki : can we please revert the use of MiMalloc on macOS?
@mocenigo
From my personal observations, this repository favors "proof of work" model and creating a PR might be a faster way to fix the issue. This time it also took a conveniently small change, compared to the volume of words in any of the comments above: https://github.com/zed-industries/zed/pull/11293
@mocenigo
From my personal observations, this repository favors "proof of work" model and creating a PR might be a faster way to fix the issue. This time it also took a conveniently small change, compared to the volume of words in any of the comments above: #11293
Thank you. Fact is, I am not versed in Rust yet, so I would just have removed the lines, and would not have made it into an optional feature…
0.133.7 seems to be very stable about memory usage so far (I did use it very little on a few files, but it still seems to not leak much, if at all)
Observed, Zed 0.133.7 is extremely stable with the memory, the compressed memory amount even goes down after a short time.
Will try upgrading to the next version.
I think I'm going to close this issue, as it seems it's been resolved with the allocator changes, I'm going to close this for now. Thanks for the investigative work everyone!
