Я использую tmux (на самом деле byobu с tmux backend) на ubuntu 14.04.
Мой tmux использует 1 ГБ памяти (VIRT и RES in top), и я уже использовал команду clear-history.
Теперь мой прокрутка отключена, но использование памяти не снижается.
Этот tmux работал в течение долгого времени, и через него прокручивалось много текста. top показывает, что он использовал более 1 часа времени процессора.
Что может быть причиной?
Может ли быть утечка памяти?
Что я могу попробовать?
Я не могу перезапустить его или делать опасные вещи, потому что сеанс запускает эксперимент, который занимает около одной недели, чтобы завершить...
Кажется, что была ошибка в tmux, в результате чего память не освобождалась при ясной истории.
Эта ошибка существовала вплоть до версии 1.9a, исправленной в версии 2.0. Я отправляю это как последний ответ, так как версия 1.9a по-прежнему используется (по крайней мере, со мной).
https://groups.google.com/forum/#!topic/tmux-users/WiSZy6ft1As https://github.com/tmux/tmux/commit/28f23f18e9d79405a60348c4f7aeded33da9135b
Поскольку никто не ответил на это, я буду предлагать свои предположения о том, что происходит.
tmux выделяет пространство в памяти для своей истории, и эта память растет, когда вы используете больше своей истории. Очистка истории делает ее невидимой, но не освобождает фактическую память. Это означает, что tmux может использовать память для общего количества строк для каждой открытой панели, независимо от того, содержат ли эти панели в настоящее время что-либо в них.
Это, возможно, ошибка, или лучшая особенность в лучшем случае.
У меня нет решения.
Это не ошибка, tmux немедленно освобождает память, когда вы очищаете историю. Это до glibc, чтобы вернуть его в ядро, и это плохо. Вы должны уметь видеть, что память свободна, потому что, если вы очистите историю на 10000 строк, использование памяти не будет расти снова, пока история снова не достигнет 10000 строк.
Другая утечка памяти была зафиксирована в 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