gpakosz / .tmux

🇫🇷 Oh my tmux! My self-contained, pretty & versatile tmux configuration made with ❤️
MIT License
22.02k stars 3.37k forks source link

High CPU usage when +3 sessions are open #247

Closed danielporto closed 4 years ago

danielporto commented 5 years ago

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.

gpakosz commented 5 years ago

Hello @danielporto,

What do you exactly call "3 terminals"? 3 instances of Terminal.app, each attached to a different tmux session?

danielporto commented 5 years ago

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

gpakosz commented 5 years ago

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?

danielporto commented 5 years ago

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.

gpakosz commented 5 years ago

You may want to try removing segments in your ~/.tmux.conf.local copy to see which causes the most activity

danielporto commented 5 years ago

I've removed the tmux.conf.local. still see CPU spikes :-(

gpakosz commented 5 years ago

Not removing ~/.tmux.conf.local, editing it and altering the content of tmux_conf_theme_status_left and tmux_conf_theme_status_right

danielporto commented 5 years ago

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

danielporto commented 5 years ago

I will keep the battery information and uptime disabled. Thanks.

gpakosz commented 5 years ago

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

gpakosz commented 5 years ago

I can't seem to reproduce the CPU spikes here 🤔

So there are 2 things:

  1. how often the status bar gets refreshed, triggering computations
  2. how heavy these computations are

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!

danielporto commented 5 years ago

Sure, thanks, I will do that over the weekend and get back with the results. Thanks for your patience.

gpakosz commented 5 years ago

@danielporto 👋

Did you find the time to make more tests by chance?

danielporto commented 5 years ago

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

gpakosz commented 5 years ago

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:

Which I'll try to address soon 🤞

gpakosz commented 5 years ago

There's the optimizations branch in which I started optimizing

danielporto commented 5 years ago

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 .

gpakosz commented 4 years ago

👋

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! 🙏

luisdavim commented 4 years ago

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?

gpakosz commented 4 years ago

@luisdavim Are you sure you checked out the latest optimizations branch and you reloaded your configuration?

luisdavim commented 4 years ago

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...

gpakosz commented 4 years ago

@luisdavim I'm surprised anything in my configuration would make tmux crash. We can discuss this again when I merge the branch

luisdavim commented 4 years ago

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

luisdavim commented 4 years ago

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.

felippemr commented 4 years ago

Using the optimizations for a while and it is great! Please merge it.

luisdavim commented 4 years ago

sorry for the bump but any updates on this? when can the optimizations branch be merged?