So a while ago I switched from screen to tmux. My reason for switching was that GNU screen didn't work in my docker containers and tmux did ;-)
All was well for a few months and I was replacing screen with tmux everywhere. It did have some other niceties besides working in containers and seem to do its job.
Until
Until
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
wim 1660 1.3 12.8 135056 131404 ? Ss 2014 722:46 tmux -u
Notice anything special above ? Compare it with screen.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
wim 29595 0.0 4.5 48784 46116 ? Ss 2014 3:49 SCREEN -c mscreen
The tmux session has 8 open windows and 10000 history limit. (set -g history-limit 10000)
The screen session has 39 open windows and 10000 history limit (defscrollback 5000)
So, tmux seems to be using an awful lot of memory. Two times more than screen, for a 'lighter' session setup.
A quick google showed that other people were having the same issues
My first thought was, 'memoryleak', so I checked the code, but everything seemed to be free'd correctly.
I joined the #tmux channel on freenode for some help and got told that it's a specific glibc (linux) issue. Although the memory was free'd, Glibc wasn't releasing it back to the OS.
But you could force it by using malloc_trim(0). And maybe you could use specific glibc environment variables to control memory allocation behaviour to also emulate malloc_trim().
Too much time googling and testing was wasted, I couldn't get it too work, the memory wasn't getting released back to the OS.
So I made a small patch to tmux which
- calls malloc_trim(0) when a window gets destroyed
- also free's memory when you clear your history manually in a window (and also call malloc_trim())
The patch works for me but YMMV
I tried to get this patch into upstream tmux, but was told: 'It's up to glibc to decide how malloc works'.
PS: if you set history-limit 0, tmux actually uses less memory than screen (and doesn't grow), but ofcourse you don't have a scrollback ;-)
Omg, I have this issue for 2 yrs! And now I begin to understand why tmux seems like have a "memory leak" problem. This is ridiculous if free() does not return to the os, for a log run process like tmux, it will occupy a large amount of memory and never be released.
ReplyDelete
ReplyDeleteJust today, I noticed the memory issue from a tmux (2.0) session which was started 3 months ago -
%CPU %MEM CMD TIME VSZ RSZ START
0.4 30.3 tmux -f .tmux.config 11:37:39 1880092 1854488 Jul 8
I found no solution and I hate to terminate the current tmux session.
This issue was addressed here - https://groups.google.com/forum/#!topic/tmux-users/WiSZy6ft1As
ReplyDelete