You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
I have the same issue.
I also notice that as soon as I am in this state, a have some huge CPU spikes each time I change window or desktop, when plug/unplug a screen or when I resume from suspend.
This is like zellij is trying to redraw everything on every pane of each tab, whether it is visible or not, because I also noticed that mem and cpu consumption is correlated to the number of tab/pane I have open (and not to the number I have visible). It happens whether session is active and visible in front or not.
I am on Archlinux, Gnome Wayland sessions (happen on both Gnome 46 and 47), Kitty terminal (happens whatever the version) and zellij 0.40.1 if this help. I have default settings except for theme, default_layout, pane_frames and keybinds obviously.
Anyway, not sure whether it helps, whether it's related, but I'll be happy to provide more details and insights if needed because this is by far my number one usability restraint (I have to kill all zellij instances multiple times a day or else my computer becomes unusable because zellij literally use all available cpu and memory during those spikes).
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.
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:
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 activatepane_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:
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:
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.
The text was updated successfully, but these errors were encountered: