Re: tmux overhead
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
Re: tmux overhead
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
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."
Re: tmux overhead
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
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
tmux overhead
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