Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RAM and CPU usage grow unbounded #3598

Open
senekor opened this issue Sep 11, 2024 · 0 comments
Open

RAM and CPU usage grow unbounded #3598

senekor opened this issue Sep 11, 2024 · 0 comments

Comments

@senekor
Copy link

senekor commented Sep 11, 2024

I have been observing this problem for a long time, but I struggle find a minimal reproduction, which is why I hesitated to open an issue. But the problem is too big not to report.

The problem is pretty similar to #1625, but that was closed a while ago as fixed. I'm running 0.40.1 and the problem is still there. The below screenshot is from sessions running over the span of one to two days, I was getting close to my 32GB RAM capacity.

image

I usually have zellij running with an instance of helix and depending on the project I'm working on some background processes in other panes, e.g. frontend / documentation dev server. Helix usually has some LSP running. When I close the tabs of the zellij sessions which are consuming insane amounts of memory, the memory consumption goes back down to normal levels. Interestingly, that also applies to tabs which weren't running anything. My "ide" layout contains a "terminal" tab that I actually rarely use. But even closing that can drop memory consumption by over 1GB. So I don't think it has to do with scrollback - these tabs don't have any scrollback.

This is a quote from the previously linked, closed issue:

Do you have a scrollback limit set?

I don't. How do you do that? Searching for "scrollback" in the zellij documentation only yields scrollback_lines_to_serialize, which doesn't apply to me since I didn't activate pane_viewport_serialization. It doesn't seem like it could be the problem anyway, since serialization would go to disk, not blow up ram usage...

The weird thing is that not all zellij sessions are affected. For example, I usually have one session running with btop. That one never blows up in memory consumption. I might try to open a couple different zellij sessions, some with background processes, some with LSP and keep them running over night, see which ones blow up in memory usage. If time allows.

The CPU usage is also notable. It was consistently high at a couple percent for each zellij server process while idling. This indicates to me that this isn't a simple memory leak.


A few thoughts about your issue template:

please note that the responsibility to troubleshoot the issue and find the problem is ultimately on your shoulders

You're the expert on your system and we believe you are in the best position to troubleshoot it. Thank you for understanding.

This is rubbing me the wrong way. You are advertising zellij to be used by the general public, who cannot be expected to fix all issues themselves. For example, a quote from your readme:

Zellij is geared toward beginner and power users alike

If I was a beginner and I woke up to zellij eating half of my 32GB of RAM and then I discovered the zellij devs expect me to troubleshoot myself (saying I am "the expert on my system") I would feel pretty betrayed by this advertisement.

I'm personally capable of troubleshooting but time is always scarce, so I can't know in advance if I will succeed in troubleshooting something myself.

I think you should make your messaging more consistent. You could either update your website and readme to clarify that this is alpha-quality software and only terminal wizards and Rust experts with time and motivation to contribute to the development should even use it. Or you could update the issue template to be more welcoming to bug reports from people with different skill levels and amounts of time to spare to contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant