当大量文本输出到终端时，有什么方法可以防止tmux冻结吗？

在xterm内的tmux会话中，当程序生成大量输出时（例如cat very_long_file整个会话冻结了一段时间。即使我按Ctrl-C，也不会中断。大概是因为tmux被冻结了，并且没有将Ctrl-C转发给程序生成输出，有什么方法可以防止这种情况。

正确的解决方案是查看tmux的c0- *选项，尝试对输出进行速率限制。根本存在此问题的原因是由于数据发送到终端的速度快于其显示的速度，因此限制速率是唯一的方法。

在Ubuntu 12.10上的tmux 1.6-2中仍然存在此问题。我发现的一种解决方法是从会话（prefix + d）中分离出来，然后重新附加（tmux attach，它是快速shell别名的理想选择）。看起来tmux实际上是在后台进行响应--您可以确认您的进程实际上已被ctrl-c立即终止--只是图被阻塞了。分离将立即生效，并且当您重新附加时，工程图将跳到最后。

据我所知，在当前版本中没有办法阻止它，但正在进行一些工作。您可以在tmux的邮件列表http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689上找到一些补丁。

搜索网络的一个很好的关键词是“流量控制”。

不幸的是，从tmux 2.1版（changelog）起，用于速率限制的c0- *选项已被删除。据我所知，自定义速率限制的唯一方法是在源代码（tmux.h）中更新影响它的变量：

“ READ_SIZE是要从pty保留的最大数据大小（事件高水位线）。READ_BACKOFF是等待pty读取之前要等待输出到tty的数据量。如果tty高于READ_BACKOFF，则进行下一次读取（以微秒为单位）。 ”

在哪里可以找到默认值：（从tmux v2.2开始）：

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100

答案https://superuser.com/a/589896/311481可以正常工作。我使用以下值：

setw -g c0-change-trigger 10
setw -g c0-change-interval 250

另一个提示：如果在tmux中使用ssh，请改用mosh：http : //mosh.mit.edu/它在显示程序输出方面表现得更聪明。在适当的情况下，它将尝试显示最后的屏幕状态下降中间值。因此，如果tmux的窗格中包含mosh会话，则在其中生成大量输出时，tmux将永远不会冻结。

与SSH不同，mosh的基于UDP的协议可以优雅地处理数据包丢失，并根据网络状况设置帧速率。Mosh不会填满网络缓冲区，因此Control-C始终可以停止失控的进程。

因为SSP（Mosh使用的状态同步协议）在对象层工作并且可以控制同步速率（换句话说，帧速率），所以它不需要发送从应用程序接收到的每个字节。这意味着Mosh可以调节帧，以免填满网络缓冲区，从而保持连接的响应速度，并确保Control-C始终快速运行。必须发送每个字节的协议无法做到这一点。

尝试使用其他终端模拟器。在RedHat 6.5上，konsole（KDE）没有冻结问题（tmux 2.3和master）；但是，xterm和gnome-terminal都遇到严重冻结。