Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tmux 2.4 consumes a lot of CPU #889

Closed
maotora opened this issue Apr 27, 2017 · 17 comments
Closed

tmux 2.4 consumes a lot of CPU #889

maotora opened this issue Apr 27, 2017 · 17 comments

Comments

@maotora
Copy link

maotora commented Apr 27, 2017

Hello,

Recently after I updated my system I was upgraded to tmux -V 2.4 which was kinda cool except when it started consuming a lot of CPU.

I'm not sure what (in tmux) is causing this asked yesterday in the IRC but most said there systems were okay (even ones using same linux distro).

I'm using ArchLinux, and here is some screenshot to explain a bit more.

Before tmux started

Before tmux

After tmux started with 2 sessions opened and 5 panes (combined).

After tmux

htop after tmux started.
htop with tmux

Now, I have to say 2.3% CPU is huge for tmux with 5 panes, but this can go up to 50% when I keep my tmux running. I'm also including sensors results cause that's what terrifies me more than the CPU usage.

My tmux configurations I should also add that I tried commenting out tmux powerline and tmux plugins but this did not help.

My hardware info if it's important.

@nicm
Copy link
Member

nicm commented Apr 27, 2017

tmux.conf?

@maotora
Copy link
Author

maotora commented Apr 27, 2017

@nicm I just posted it it's a bit long so I thought I should use a link instead.

@nicm
Copy link
Member

nicm commented Apr 27, 2017

Can you reproduce without a tmux.conf?

@maotora
Copy link
Author

maotora commented Apr 27, 2017

Oddly enough, it started and stayed smooth.
But what's in my tmux.conf that makes it aggressive then?

Update.

It's powerline not sure why, but only the tmux one does this in tmux though (as I'm using powerline in zsh too).
I tried commenting out the line sourcing powerline and it did the trick.

Thank you for your support @nicm

@nicm
Copy link
Member

nicm commented Apr 27, 2017

I don't know, start commenting stuff out until you find the problem? I'd start with all the tpm stuff at the end.

@pjcj
Copy link

pjcj commented Apr 29, 2017

I'm not convinced this is a powerline problem. See my analysis in the bug referenced above.

Is it possible that display -p is triggering a status line redraw?

@nicm
Copy link
Member

nicm commented Apr 30, 2017

I don't know if it is powerline or not but I'm not going to try and work it out from a 200 line config file.

I don't think display -p does a redraw and it doesn't seem to for me. What do the tmux logs look like when you do it? Do you see it sending the status line to the terminal (look for "[display-message]" then lines starting "/dev/ptywhatever:" and your status line contents).

@nicm nicm reopened this Apr 30, 2017
@nicm
Copy link
Member

nicm commented Apr 30, 2017

I think 7d23d01 is possibly going to be hurting you here. But this would be a lot quicker if you could please create a small standalone config file to reproduce then show me it and tmux logs demonstrating the problem.

@nicm
Copy link
Member

nicm commented Apr 30, 2017

Hmm no you are using status-right so maybe something else.

@jungle-boogie
Copy link

FYI, here's another issue related to powerline, tmux and high CPU usage: #361

@pjcj
Copy link

pjcj commented Apr 30, 2017

I have narrowed down the problem:

.tmux.conf has a single line: set-option -g status-right "#(echo #D)"

Run tmux new in two terminals.

Workaround: set-option -g status-right "#(echo '#'D)"

I trust this will be sufficient to show the problem. Thanks!

@nicm
Copy link
Member

nicm commented Apr 30, 2017

Great, I can reproduce with this.

So the problem is because tmux will bypass the "only once a second" rule for jobs (that is, #()) where the expanded form has changed. And because you have two clients with different sessions, it is always changing because the two clients have different active panes so for one #D will be %0 and for the other it'll be %1.

The idea behind this was that people who have, for example, #(myscript #D) in windows with multiple panes don't have to wait for a second before the status line updates when they switch pane.

I think the best way to fix this for both cases is by tying the job to a particular client when possible (so each client has its own list of jobs). Please try this: a.diff.txt

@nicm
Copy link
Member

nicm commented Apr 30, 2017

Your workaround works because the expansion is happening at a different point. The expanded command is "echo '#'D" which never changes, so tmux runs it at most once a second. The expansion of #D happens on the output of the echo, instead of on the echo command itself:

#(echo #D) -> #(echo %0) -> %0 -> %0
#(echo '#'D) -> #(echo '#'D) -> #D -> %0

@pjcj
Copy link

pjcj commented Apr 30, 2017

That fix looks to be working fine. Thanks for identifying and fixing it so quickly!

@m1cr0man
Copy link

Hello!

A couple of days ago I ran into this issue myself and reported it on the IRC as I didn't have time to make an issue and help debug it. I just tried that patch myself and it seems to have corrected the issue for me too. I'm not using Powerline but I do have my own quite complicated status-left and -right texts.

Thanks for resolving this one so quickly! It was a bummer having my status bar disabled for the last few days 👍

@nicm
Copy link
Member

nicm commented May 1, 2017

Applied now, thanks.

@nicm nicm closed this as completed May 1, 2017
michojel added a commit to michojel/arch that referenced this issue May 8, 2017
Backports: tmux/tmux@0ccfb61

Fixes: tmux/tmux#889

Signed-off-by: Michal Minář <mic.liamg@gmail.com>
michojel added a commit to michojel/arch that referenced this issue May 8, 2017
Backports: tmux/tmux@0ccfb61

Fixes: tmux/tmux#889

Signed-off-by: Michal Minář <mic.liamg@gmail.com>
@lock
Copy link

lock bot commented Feb 16, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

5 participants