Re: tmux overhead

[Rhialto]

On Fri 22 Jan 2016 at 05:57:44 +, Michael van Elst wrote:
> The window name is refreshed twice a second:

I think you can turn that off:

set-window-option -g automatic-rename off

I tried once to replace screen with tmux, but there was something
important that I was missing. I think it was the ^A F command (force
window resize) or something like  that.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature

Re: tmux overhead

[Andrei M.]

The Linux version of tmux is notorious for a noticeable CPU overload
too (try Google 'tmux CPU usage'), something to do with the original
design.

2016-01-22 1:59 GMT+03:00 John Klos :
> Hi, all,
>
> Since tmux is part of a standard NetBSD install, I've been using it instead
> of screen. So far, so good. However, I've noticed that it accumulates a LOT
> of CPU time even when the underlying tty and shell are doing absolutely
> nothing. On a 60 MHz m68060 system that's been up for 53 days, for instance,
> and with a shell that's sitting at a quiet prompt:
>
> 25403 john  850  6144K 2312K kqueue44.1H  4.05%  4.05% tmux
>
> 44 HOURS? Wow. And while it's otherwise idle, it's taking around 4% CPU.
>
> Ideas about why this is so busy?
>
> John

tmux overhead

[John Klos]

Hi, all,

Since tmux is part of a standard NetBSD install, I've been using it 
instead of screen. So far, so good. However, I've noticed that it 
accumulates a LOT of CPU time even when the underlying tty and shell are 
doing absolutely nothing. On a 60 MHz m68060 system that's been up for 53 
days, for instance, and with a shell that's sitting at a quiet prompt:


25403 john  850  6144K 2312K kqueue44.1H  4.05%  4.05% tmux

44 HOURS? Wow. And while it's otherwise idle, it's taking around 4% CPU.

Ideas about why this is so busy?

John

Re: tmux overhead

[Swift Griggs]

On Thu, 21 Jan 2016, John Klos wrote:

Ideas about why this is so busy?


No. However, you could try to profile it to find out. Run it in ktrace(1) 
and/or do a gdb -attach to it's PID. Then start looking at the trace 
output to see what kind of library functions it's running in it's main 
event loop. Use kdump to view the ktrace output. That may give you some 
idea.


If you've already tried that... there is always fprintf() logging 
statements stuffed in the code in key places to see what bits of logic are 
getting the most action.


  Swift

Re: tmux overhead

[J. Lewis Muir]

On 1/21/16 4:59 PM, John Klos wrote:
> Ideas about why this is so busy?

Hi, John.

It might be worth looking into what version of tmux is in the NetBSD
version you have installed; maybe it has inefficiencies?  Ted Unangst
has a blog post at [1] titled "rough idling" where he talks about the
situation you're seeing in general and also mentions that a number of
efficiency fixes were made to the tmux in OpenBSD after the OpenBSD 5.8
release.  I don't know if the same fixes made it into the version of
tmux you have; maybe it's worth a look.

Regards,

Lewis

[1] http://www.tedunangst.com/flak/post/rough-idling

Re: tmux overhead

[Michael van Elst]

jlm...@imca-cat.org ("J. Lewis Muir") writes:

>version you have installed; maybe it has inefficiencies?  Ted Unangst
>has a blog post at [1] titled "rough idling" where he talks about the
>situation you're seeing in general and also mentions that a number of
>efficiency fixes were made to the tmux in OpenBSD after the OpenBSD 5.8
>release.

The window name is refreshed twice a second:

 19193  1 tmux 1453438853.358587124 __kevent50(0x3, 0x7bc03000, 0, 
0x7bc03800, 0x40, 0x7fffc330) = 0

update_time_cache() (in libevent)
{
 19193  1 tmux 1453438853.358604936 __clock_gettime50(0x3, 0x7fffc330) 
= 0
 19193  1 tmux 1453438853.358613894 __gettimeofday50(0x7fffc340, 0) = 0
}

 19193  1 tmux 1453438853.358643738 __gettimeofday50(0x7fffc2f8, 0) = 0
 19193  1 tmux 1453438853.358655873 __gettimeofday50(0x7fffc300, 0) = 0

gethostname()
{
 19193  1 tmux 1453438853.358713008 __sysctl(0x7fffc208, 0x2, 
0x7fffc228, 0x7fffc204, 0, 0) = 0
}

osdep_get_name()
{
 19193  1 tmux 1453438853.359059412 __stat50("/dev/pts/6", 0x7fffc228) 
= 0
 19193  1 tmux 1453438853.359079933 ioctl(0xb, TIOCGPGRP, 0x7fffc1e4) = 0
   "n<\0\0"
 19193  1 tmux 1453438853.359247015 __sysctl(0x7fffc210, 0x6, 0, 
0x7fffc20c, 0, 0) = 0
 19193  1 tmux 1453438853.359288681 mmap(0, 0x40, 0x3, 0x14001002, 
0x, 0, 0, 0) = 0x7b80
 19193  1 tmux 1453438853.359530555 __sysctl(0x7fffc210, 0x6, 
0x7b80, 0x7fffc20c, 0, 0) = 0
 19193  1 tmux 1453438853.359604513 munmap(0x7b80, 0x40) = 0
}

 19193  1 tmux 1453438853.359838573 __gettimeofday50(0x7bc540e0, 0) = 0
 19193  1 tmux 1453438853.359870032 __clock_gettime50(0x3, 0x7fffc330) 
= 0
 19193  1 tmux 1453438853.359877896 __gettimeofday50(0x7fffc340, 0) = 0
 19193  1 tmux 1453438853.359885032 __clock_gettime50(0x3, 0x7fffc330) 
= 0
 19193  1 tmux 1453438853.359892740 __gettimeofday50(0x7fffc340, 0) = 0

netbsd-current got a new version about two weeks ago that should behave better.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."