Closed danielporto closed 4 years ago
Hello @danielporto,
What do you exactly call "3 terminals"? 3 instances of Terminal.app
, each attached to a different tmux session?
Yep, 3 instances of Terminal.app or iTerm2 or a mix of them. each one creating a new tmux session. opening Bash (or fish or zsh) Unmodified tmux.conf.local and tmux.conf
Well, what's going to happen with 3 tmux client running is that each of them is going to refresh its status line at a regular interval (by default 10s but it may be more often).
Each time the status bar refreshes itself, things are happening: typically cut -c3- ~/.tmux.conf |sh -s <some function name>
runs and this creates activity.
If you do
$ tmux set -g status-left ''
$ tmux set -g status-right ''
And if CPU spikes disappear, it will validate the activity is caused by launching shell processes when refreshing the status bar.
BTW which version of tmux are you using?
Indeed, the commands (specially the second one) eliminate the CPU spikes along side all the bar features. I was using the latest version of tmux. 2.9a then upgraded to HEAD (3.0) but the problem shows in both.
You may want to try removing segments in your ~/.tmux.conf.local
copy to see which causes the most activity
I've removed the tmux.conf.local. still see CPU spikes :-(
Not removing ~/.tmux.conf.local
, editing it and altering the content of tmux_conf_theme_status_left
and tmux_conf_theme_status_right
When disabling tmux_conf_theme_status_right, tmux_conf_theme_status_left is responsible for about 33% of cpu usage after 3 terminals open.
when disabling tmux_conf_theme_status_left (let the string ' ❐ #S | ' only) , tmux_conf_theme_status_right enabled, hits 100% after the 4th terminal open.
the the following minimum settings: tmux_conf_theme_status_left=' ❐ #S | ' tmux_conf_theme_status_right='%R , %d %b | #{username}#{root} | #{hostname} ' CPU is in normal state, with mostly low CPU usage even with 8 Terminal.app open all with new sessions
I will keep the battery information and uptime disabled. Thanks.
Thanks for the tests. I'm keeping this issue open so that I can investigate further and hopefully find a way to reduce the CPU usage
I can't seem to reproduce the CPU spikes here 🤔
So there are 2 things:
Can you please make the following experiment which consists in launching tmux with stock / empty configuration then alter status-right
to trigger computations upon status bar refresh. To better observe CPU usage, close other tmux sessions, web browser (here Chromes does a lot in the background), ...
$ tmux -f /dev/null
Then create multiple sessions, say 4.
Then open 4 terminal instances and in each attach to tmux
$ tmux attach
Now. open a 5th terminal instance and do
$ touch /tmp/log.txt
$ tail -f /tmp/log.txt
Now go back to any of the terminals in which you attached to tmux and do
$ tmux set -g status-right '#(date +%%s >> /tmp/log.txt)'
You should see 4 entries in /tmp/log.txt
with the same timestamp (it's the 4 tmux clients refreshing their status bar) then entries shouldn't appear in packets of 4 and should appear way less often (roughly every 10 - 15s).
Then you can try replacing the date +%%s
command by sysctl -q -n kern.boottime | awk -F'[ ,:]+' '{ print $4 }'
which is what I use for uptime computations. And see whether calling sysctl
makes you observe higher CPU usage.
$ tmux set -g status-right '#(sysctl -q -n kern.boottime | awk -F'[ ,:]+' '{ print $4 }' >> /tmp/log.txt)'
Thanks!
Sure, thanks, I will do that over the weekend and get back with the results. Thanks for your patience.
@danielporto 👋
Did you find the time to make more tests by chance?
Hello @gpakosz , Sorry for the long delay. Since disabling stuff worked for me this test has to go down the todo list. But now I did it. And... CPU usage for both commands is barely minimum. Nothing changed even with 5 tmux sessions in 5 different iterm + 1 to monitor the log file (excerpt at the end).
Btw, I updated tmux.conf and tmux.conf.local to the latest version and the problem remains. >.< I also formatted my laptop. It's a brand new system. Now macOS Mojave.
output: 1561714261 1561714261 1561714261 1561714261 1561714261 1561714263 1561714264 1561714264 1561714266 1561714275 1561714278 1561714279 1561714279 ... 1561714461 1561714470 1561714473 1561714474 1561714474 1561714476 1561714476 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019 { sec = 1561541637, usec = 957101 } Wed Jun 26 10:33:57 2019
Hello @danielporto
The experiment's goal is for you to have a sense of whether tmux updates the status line too often.
My expectation is that status line should be updated every x
seconds, where x
corresponds to the value of status-interval
.
Or the status line should be updated when you switch pane ← this is because I use #D
as an argument to some of the helpers that implement the custom variables (e.g. #{root}
, #{username}
, #{hostname}
, ...).
In any case I have ideas on 2 fronts:
#{uptime_y}
, #{uptime_d}
, #{uptime_m}
, #{battery_status}
, ...)Which I'll try to address soon 🤞
There's the optimizations
branch in which I started optimizing
Thank you. I will give a try and report back to you.
sent from my mobile.
On Sun, Sep 22, 2019, 1:43 PM Gregory Pakosz notifications@github.com wrote:
There's the optimizations branch in which I started optimizing
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gpakosz/.tmux/issues/247?email_source=notifications&email_token=AAMTRG6SI4GKKTPCYSYPD5LQK5SA7A5CNFSM4HNYLARKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7JFQSI#issuecomment-533878857, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMTRG33CLULFVVCKS24UALQK5SA7ANCNFSM4HNYLARA .
👋
I'm close to landing the optimizations
branch, those following this issue can you please give it a try?
$ cd ~/.tmux
$ git stash
$ git fetch -p
$ git checkout optimizations
$ git reset --hard origin/optimizations
Then hit <prefix> + r
to reload the configuration.
Thanks! 🙏
Hi, I'm seeing the same issue even with just 2 terminals open, the top processes are:
sh -s _uptime
sh -s _battery
sh -s _hostname ....
sh -s _username ....
sh -s _root ....
is there a way to configure how often to update the status bar?
@luisdavim Are you sure you checked out the latest optimizations
branch and you reloaded your configuration?
Oh, I wasn't using the optimizations
branch but once I've switched to that and killed all my terminals I was unable to open new terminals as tmux
would crash an the terminal would close itself...
@luisdavim I'm surprised anything in my configuration would make tmux
crash. We can discuss this again when I merge the branch
This is my tmux.conf.local: https://github.com/luisdavim/dotfiles/blob/master/files/shell/tmux.conf.local (it's not that different from the one in your repo) and I'm using the oh-my-zsh tmux plugin to start tmux https://github.com/luisdavim/dotfiles/blob/master/files/shell/zsh/zshrc
hi, any updates on this? When will the optimisations brach be merged? I've tested the latest version of that branch and I no longer get the crashes I was getting before.
Using the optimizations
for a while and it is great! Please merge it.
sorry for the bump but any updates on this? when can the optimizations
branch be merged?
I'm using macOS HighSierra, when open 3 terminals and a new session in each one of them (simply run tmux) the CPU spikes and the terminal usage keeps at 100% even though nothing is being used. I tested with bash as the shell but I've seen the same behavior with fish and zsh. Tried with iTerm2 too. I also tested with the unmodified tmux.conf/tmux.conf.local files.
Finally, I tested with an Empty tmux file and I can open as many terminals I want and the CPU keeps in check with low usage.