我在ubuntu 14.04上使用tmux（事实上是byobu和tmux后端）。
我的tmux使用1GB内存（top中的VIRT和RES），我已经使用了clear-history命令。
现在我的回滚已经消失，但内存使用量没有下降。
这个tmux已经运行了很长时间，很多文本都滚动了它。 top显示它总共使用了超过1小时的CPU时间。
可能是什么原因？
是否有内存泄漏？
我能尝试什么？
我无法重新启动或执行危险的操作，因为会话运行的实验需要大约一周才能完成......
答案 0 :(得分：8)
tmux中似乎存在一个错误，导致内存在历史记录中没有被释放。
此错误存在，包括版本1.9a，已在2.0版中修复。我发布这个作为一个迟到的答案，因为版本1.9a似乎仍然在使用（至少与我一起）。
https://groups.google.com/forum/#!topic/tmux-users/WiSZy6ft1As https://github.com/tmux/tmux/commit/28f23f18e9d79405a60348c4f7aeded33da9135b
答案 1 :(得分：5)
由于没有人回答这个问题，我会提出我对发生的事情的猜测。
tmux在内存中为其历史记录分配空间，并且当您耗尽更多历史记录时，内存会增长。清除历史使其不可见，但不会释放实际的记忆。这意味着tmux可以使用内存占用每个打开窗格的总行数，无论这些窗格当前是否包含任何内容。
这可以说是一个错误，或者说是一个糟糕的特征。
我没有解决方案。
答案 2 :(得分：2)
这不是一个错误，当你清除历史记录时，tmux会立即释放内存。由glibc将其返回到内核并且它很糟糕。您应该能够看到内存是空闲的，因为如果您清除10000行的历史记录，则在历史记录再次达到10000行之前，内存使用量不会再次增长。
答案 3 :(得分：1)
在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
答案 4 :(得分：1)
Necropost，但这个问题一直持续到最近。来自x86 xubuntu 18.04上的回购协议的tmux 2.6的内存使用总是在一两天之内爬升到1 GB。我将其删除并从源代码构建了tmux 2.8。几天来它的内存使用量一直很少。问题终于解决了。