zellij
zellij copied to clipboard
zellij-org
High CPU usage on version 0.39.0
I just installed the new version 0.39.0 and I see the CPU usage rose significantly. On version 0.38.2, the CPU usage of Zellij is under 1 %. On version 0.39.0 it is about 14-15 %. In both cases I have only one pane open and nothing else is running in the session.
My CPU: Intel i7-9750H (12) @ 4.5GHz Considering that Zellij takes 15 % of CPU time while doing nothing on this CPU, I think 5th generation Intel CPU in my old X250 will not like it at all and it will be much more.
0.38.2
0.39.0
PS: Otherwise, I am really happy to see session resurrection and tab renaming features! :relaxed:
I think that this is related to the session resurrection PR, compiling 9e8ebe465be0804a718c430f248165c44ed51972 gives me low usage, while with 3e31a0e3474c3ffe8ea8085303651798647ec4cb it goes up.
I have similar experience. htop is oscilating between ~6% and 13% CPU usage, while the command watch -n1 -d "ps -o pid,%cpu,cmd -C zellij" shows always 9.9% CPU.
We serialize sessions once per second now, might need to be tweaked (and/or exposed as a config variable). Just to make sure, does setting session_serialization false in the config remove this issue?
We serialize sessions once per second now, might need to be tweaked (and/or exposed as a config variable). Just to make sure, does setting
session_serialization falsein the config remove this issue?
Yes, it does.
Gotcha, thanks. I'll tweak this a little and release a patch in the next week or so (I want to wait to see if other issues bubble up).
If you want to make the serialization frequency a configuration variable, I'd be happy to take that PR on.
FWIW, tmux-continuum saves the session state every 15 minutes. I think once per second is pretty eager.
My suggestions are:
- Creating a configuration variable for serialization frequency (for those who want automatic serialization)
- Serialize on detach or quit (automatic serialization but CPU friendly)
- Serialize ONLY on demand
- I think this is also useful. For example, you take your time and set a perfect layout and then you save it. After that, you accidentally close some panes or for testing purpose you create some floating panes which you don't want next time you will start working with this session. If auto serializtion is on, like now, then it will override your settings and you can not prevent that.
If it is not too complicated, I would suggest that serialization is done only if the layout has been changed from the last saving.
Hey @mike-lloyd03 - a PR for this would be greatly appreciated! I want to release a patch version next week on Monday morning. Do you think you can get it in before then?
As for solutions: for now let's go with making the time configurable session_serialization_frequency <seconds> and let's default to 60. I get what you're saying about tmux-continuum, but I want to give a better experience here. More like browser crashes, I guess. If it doesn't work well, users can configure it away and we can tweak the default further at a later time.
I took at look at it last night and it appears we need to make SESSION_READ_DURATION in zellij-server/sec/background_jobs.rs read from the config kdl. I couldn't find a quick way to do this so it'll take me some time.
I'm actually going camping tomorrow and won't be able to work on this until I'm back on Sunday. So if someone else can work on it before then, that'd be great. Otherwise, I can do it, but I doubt it'll be done by Monday your time.
Also, this will be greatly mitigated by https://github.com/zellij-org/zellij/pull/2920 - though I still want to go for a 1 minute default.
I am very surprised session_serialization is even enabled by default. This seems like a very niche feature with an inevitable performance cost, even if we reduce that cost.
if we reduce that cost
though I still want to go for a 1 minute default
And even 1 minute might be too much, I think. One usually sets panes and tabs, and then rarely touches the configuration. So saving often might be pointless. On the other hand, if the state of running programs would persist between sessions resurrections, then frequent saving would be actually useful. When I resurrect my session after restart, then
- all my Python venvs are not activated anymore
- the Ranger program has all tabs closed and is inside home directory
- ipython REPLs loose all loaded data I worked with
It would be nice if dev environment survived as well. :smile:
Zellij 0.40.1 uses CPU even when it should be idle. It issues syscalls (including filesystem) periodically. Here is a minute of idling syscalls:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ------------------
81.99 0.566412 822 689 16 futex
13.67 0.094475 800 118 epoll_wait
1.44 0.009966 9966 1 wait4
0.81 0.005563 6 796 56 openat
0.44 0.003044 3 857 59 read
0.30 0.002085 2 746 close
0.28 0.001900 2 819 sched_yield
0.20 0.001357 7 178 write
0.16 0.001095 3 278 getdents64
0.15 0.001065 0 1374 472 statx
0.14 0.000966 8 118 118 mkdir
0.13 0.000875 3 238 epoll_ctl
0.11 0.000749 2 327 36 newfstatat
0.07 0.000514 4 120 timerfd_settime
0.03 0.000209 3 57 readlink
0.03 0.000206 1 114 lseek
0.02 0.000139 2 69 mmap
0.01 0.000098 19 5 munmap
It writes the same session_info/.../session-metadata.kdl and session_info/.../session-layout.kdl files again and again, then iterates all the sessions for some reason using directory traversal syscalls.
I think Zellij should only save session when something in that session has been changed and should just idle completely (no CPU, no syscalls) when there are no user interactions and all programs started by Zellij do not output anything.
