19

I use tmux (in fact byobu with tmux backend) on ubuntu 14.04.

My tmux uses 1GB of memory (VIRT and RES in top) and I have already used the clear-history command.

Now my scrollback is gone but the memory usage is not going down.

This tmux was running for a long time and lots of text scrolled through it. top shows it used more than 1 hour of CPU time in total.

What could be the reason?

Could there be a memory leak?

What could I try?

I cannot restart it or do dangerous things because the session runs an experiment that takes around one week more to complete...

peschü
  • 1,299
  • 12
  • 21

5 Answers5

10

There seems to have been a bug in tmux, resulting in memory not being freed on a history clear.

This bug existed up to including version 1.9a, fixed in version 2.0. I'm posting this as a late answer, as version 1.9a seems to be still in use (with me at least).

https://groups.google.com/forum/#!topic/tmux-users/WiSZy6ft1As https://github.com/tmux/tmux/commit/28f23f18e9d79405a60348c4f7aeded33da9135b

sstn
  • 3,050
  • 19
  • 32
6

Since no one has answered this, I'll offer my speculation on what's happening.

tmux allocates space in memory for its history, and that memory grows as you use up more of your history. Clearing history makes it invisible, but doesn't free up the actual memory. This means that tmux can use memory up the total number of lines for each open pane, regardless of whether those panes currently contain anything in them.

This is arguably a bug, or a bad feature at best.

I don't have a solution.

quant
  • 21,507
  • 32
  • 115
  • 211
4

Necropost, but this problem has persisted for me until very recently. The memory use of tmux 2.6 from the repos on x86 xubuntu 18.04 always crept up to a gigabyte within a day or two. I removed it and built tmux 2.8 from source. Its memory usage has been minimal for several days. Problem solved, finally.

alazyworkaholic
  • 537
  • 2
  • 8
3

Another memory leak was fixed in tmux 2.5:

* Handle slow terminals and fast output better: when the amount of data
  outstanding gets too large, discard output until it is drained and we are
  able to do a full redraw. Prevents tmux sitting on a huge buffer that the
  terminal will take forever to consume.

* Do not redraw a client unless we realistically think it can accept the data -
  defer redraws until the client has nothing else waiting to write.

https://github.com/tmux/tmux/blob/91b220525b0406763dafb6698d2741bec580bc10/CHANGES#L257-L263

Ivan Kozik
  • 845
  • 8
  • 12
2

It's not a bug, tmux does free memory immediately when you clear the history. It's up to glibc to return it to the kernel and it is poor at that. You should be able to see the memory is free because if you clear the history at say 10000 lines, the memory usage will not grow again until the history again reaches 10000 lines.

  • Would glibc return the memory to the kernel sooner if the machine is heavily swapping pages in and out (because it does not have any free memory left)? – peschü Jan 15 '15 at 05:59