.tmux: High CPU consumption usage

When running tmux v2.2 with this .tmux configuration under MSYS2, CPU usage goes russian mountains, with big spikes attributed to a system process.

This doesn’t happen when running tmux without this .tmux.conf .

I suspect an issue with some system call such as battery level.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 4
  • Comments: 36 (16 by maintainers)

Commits related to this issue

Most upvoted comments

In case anyone here is using OS X + Homebrew you can install tmux directly from their git repository:

tmux kill-server #  Will stop everything. You can also close it manually.
brew unlink tmux # Unlink version 2.4. 
brew install tmux --HEAD

Start tmux again and you will be able to use tmux_conf_theme_status_right without experiencing high CPU usage.

My mistake.

By now,

  • #{loadavg} is you use it is refreshed in a background job, at most every status-interval seconds
  • if you use #{uptime_s}, uptime information is refreshed in a background job every seconds otherwise every minute
  • #{battery_bar} and #{battery_percentage} is always refreshed in a background job at most every minute
  • #{battery_status} is refreshed when the status bar is refreshed (every status-interval seconds)
  • #{username} is refreshed when the status bar is refreshed (every status-interval seconds)
  • #{root} is refreshed when the status bar is refreshed (every status-interval seconds)
  • #{hostname} is refreshed when the status bar is refreshed (every status-interval seconds)

So that “heartbeat” must correspond to tmux refreshing the status line every status-interval seconds. Keep also in mind tmux refreshes the status bar when you hit <prefix>.

Hope that sheds some light 🙂

I was having this same issue on a Centos 6.9 server running tmux 2.4.2.gf.el6. After reading these comments I edited the ‘.tmux.conf’ to change _username and _hostname functions to be specific: _username() { echo "$USER" } _hostname() { echo "$HOSTNAME" } I also removed all the battery references and most of the “#{xxxx}” references from tmux_conf_theme_status_right: tmux_conf_theme_status_right=' %R , %d %b | #{username} | #{hostname} ' This has fixed the High CPU usage for me for now. On the other hand i have a feeling the issues is related to “#{pane_tty}” because everywhere it is referenced and it gets called, my CPU usage instantly goes to 100%.

Yes it definitely looks like my configuration is affected by https://github.com/tmux/tmux/issues/889.

If you do

$ tmux show -g status-right

You will notice that #{username} and #{hostname} implementation expands to

#(cut -c3- ~/.tmux.conf | sh -s _username #{pane_tty} false #D)

and

#(cut -c3- ~/.tmux.conf | sh -s _hostname #{pane_tty} false #D)

Added label external because while I could find a way to optimize things, it seems forking in Cygwin and MSYS2 is generally sow and that’s something I can’t really improve.

BTW @Cyan4973, with Windows 10 creators update, if you uninstall and reinstall Bash for Windows (to get it updated to Xenial instead of Trusty), this configuration works like a charm provided you replace bold with none in your ~/.tmux.conf.local copy since currently the new Windows console has troubles applying both colors and bold attributes to rendered text.

@gpakosz Could you merge this branch to master or are there relevant parts like testing missing?

I’ve been using the optimizations branch for more than a month without excess CPU usage. Latest pull is still good.

👋

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

@hg-zt

Thanks for testing.

Yeah I parse tmux_conf_theme_status_left and tmux_conf_theme_status_right content to produce status-left and status-right values. In the process #{username}, #{root} and #{hostname} are respectively replaced by:

  • #(cut -c3- ~/.tmux.conf | sh -s _username #{pane_tty} true #D)
  • #(cut -c3- ~/.tmux.conf | sh -s _root #{pane_tty} #D)
  • #(cut -c3- ~/.tmux.conf | sh -s _hostname #{pane_tty} true #D)

Which you can see when you inspect the output of tmux show -gv status-right.

Every time you change the “current pane”, the values of #{pane_tty} and #D change and tmux executes the command again. This is effectively needed because you want the username, root flag and hostname information to update as quickly as possible. And when you don’t change pane, tmux will execute the commands again every status-interval seconds which is set to 15 in the optimizations branch.

Finally, the implementation of _username(), _root() and _hostname() requires doing non trivial work after having inspected the output of ps for the TTY specified by #{pane_tty}. From there it finds out which user is running the command and whether the user is the root user. It also tries out to detect the current command is a ssh process and if yes does more work to find out which is the remote user connected to the remote host. I still need to figure out how to minimize the work needed there.

@gpakosz

Hi, I’ve tried the latest optimizations and reset options in .tmux.conf.local for testing. I found all the battery parts no longer cause significant cpu usage even on an arm platform. While the last parts of tmux_conf_theme_status_right ( #{username}#{root} | #{hostname}) still cause spikes (see below). After removing the these parts, spikes disappeared.

PS. Here’s the output of pidstat -T CHILD -p $tmux_server_pid 1 for the default .tmux.conf.local

output
09:36:52 PM   UID       PID    usr-ms system-ms  guest-ms  Command
09:36:53 PM  1001     25697         0         0         0  tmux: server
09:36:54 PM  1001     25697         0         0         0  tmux: server
09:36:55 PM  1001     25697         0         0         0  tmux: server
09:36:56 PM  1001     25697         0         0         0  tmux: server
09:36:57 PM  1001     25697         0         0         0  tmux: server
09:36:58 PM  1001     25697         0         0         0  tmux: server
09:36:59 PM  1001     25697         0         0         0  tmux: server
09:37:00 PM  1001     25697         0         0         0  tmux: server
09:37:01 PM  1001     25697         0         0         0  tmux: server
09:37:02 PM  1001     25697         0         0         0  tmux: server
09:37:03 PM  1001     25697         0         0         0  tmux: server
09:37:04 PM  1001     25697         0         0         0  tmux: server
09:37:05 PM  1001     25697        80       170         0  tmux: server
09:37:06 PM  1001     25697       150       360         0  tmux: server
09:37:07 PM  1001     25697         0         0         0  tmux: server
09:37:08 PM  1001     25697         0         0         0  tmux: server
09:37:09 PM  1001     25697         0         0         0  tmux: server
09:37:10 PM  1001     25697         0         0         0  tmux: server
09:37:11 PM  1001     25697         0         0         0  tmux: server
09:37:12 PM  1001     25697         0         0         0  tmux: server
09:37:13 PM  1001     25697         0         0         0  tmux: server
09:37:14 PM  1001     25697         0         0         0  tmux: server
09:37:15 PM  1001     25697         0         0         0  tmux: server
09:37:16 PM  1001     25697         0         0         0  tmux: server
09:37:17 PM  1001     25697         0         0         0  tmux: server
09:37:18 PM  1001     25697         0         0         0  tmux: server
09:37:19 PM  1001     25697         0         0         0  tmux: server
09:37:20 PM  1001     25697        80       200         0  tmux: server
09:37:21 PM  1001     25697       150       320         0  tmux: server
09:37:22 PM  1001     25697         0         0         0  tmux: server
09:37:23 PM  1001     25697         0         0         0  tmux: server
09:37:24 PM  1001     25697         0         0         0  tmux: server
09:37:25 PM  1001     25697         0         0         0  tmux: server
09:37:26 PM  1001     25697         0         0         0  tmux: server
09:37:27 PM  1001     25697         0         0         0  tmux: server
09:37:28 PM  1001     25697         0         0         0  tmux: server
09:37:29 PM  1001     25697         0         0         0  tmux: server
09:37:30 PM  1001     25697         0         0         0  tmux: server
09:37:31 PM  1001     25697         0         0         0  tmux: server
09:37:32 PM  1001     25697         0         0         0  tmux: server
09:37:33 PM  1001     25697         0         0         0  tmux: server
09:37:34 PM  1001     25697         0         0         0  tmux: server
09:37:35 PM  1001     25697       190       420         0  tmux: server

It appears every ~15 secs. On a desktop computer it consumes less usr-ms and system-ms.

I’m wondering if this could be related? https://github.com/tmux/tmux/issues/889

When I set tmux_conf_theme_status_right='', the issue seems to vanish.

Ninja Edit: I’m fairly certain that this is the problem (at least for me). As soon as I have any #-style elements in tmux_conf_theme_status_right, I see the CPU spike again. Hopefully once the patch for the above issue reaches a release, it won’t be a problem. Sorry for the spam!

Hello Yann,

I got tmux working on my workstation within msys2 but well there’s no battery to query. I can’t seem to reproduce the spikes you’re mentioning.

Anyways, in the meantime I try on a laptop what you can do is edit your local ~/.tmux.conf.local copy (see instructions if you didn’t cp ~/.tmux.conf/.tmux.conf.local ~/.tmux.conf.local. And then replace

tmux_conf_theme_status_right='#{prefix}#{pairing}#{?battery_status, #{battery_status},}#{?battery_bar, #{battery_bar},}#{?battery_percentage, #{battery_percentage},} , %R , %d %b | #{username}#{root} | #{hostname} '

by

tmux_conf_theme_status_right='#{prefix}#{pairing} , %R , %d %b | #{username}#{root} | #{hostname} '

Hmm, I gave it a spin and installed tmux-git-2.1.263.g5083e93-1 package which reports 2.2 version.

When I launch tmux with my configuration, tmux crashes 😦 Gonna investigate more