我有一个在ESX4.0服务器上运行的debian虚拟机。 这个虚拟机承载了许多用户，每个用户在一个屏幕实例中运行一个irssi会话。
除了一个用户，这工作得很好。 出于某种原因，这个irssi会话在CPU使用率达到100％的时候达到峰值（同时继续正常工作）。 它没有运行任何脚本，这些脚本没有在其他更健全的irssi会话上加载。
100％的CPU不会立即启动，但通常在启动后的几个小时内。 它永远不会消失。
你将如何去debugging这个问题的来源？ 我尝试了使用strace，并没有立即看到任何明显的东西，尽pipe在开始和结束之后肯定有不同的模式。
开始时，这是30秒以上的调用直方图：
time: 334 gettimeofday: 317 poll: 122 read: 9 write: 2 restart_syscall: 1 一旦CPU开始挂钩，我得到这个：
gettimeofday: 230176 read: 115122 poll: 115106 time: 531 write: 107 waitpid: 38 _llseek: 2 ioctl: 2 fstat64: 2 open: 2 close: 2 fcntl64: 2 unlink: 1
挂钩过程的“ltrace -S”直方图显示这些作为最重要的条目：
SYS_read: 61731 g_io_channel_read: 34115 SYS_gettimeofday: 24662 SYS_poll: 12344 fflush: 6828 g_main_context_iteration: 6823 __ctype_toupper_loc: 4025 g_strcasecmp: 3757 g_hash_table_lookup_extended: 3325 g_direct_hash: 3068
我错过了什么？ 解决这个问题的下一步是什么？
我认为你需要弄清楚它是如何读取（）和轮询（）的。 由于它不是经常打开和closures新文件 – 每30秒只有两个，显然 – lsof应该告诉你。
如果从pipe道读取（），如下所示：
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME irssi 4993 user 5w FIFO 0,6 2941908 pipe
然后在所有进程中以root身份运行lsof，并在其输出中为pipe道grep（命名pipe道的名称或未命名pipe道的节点编号）。 （在这种情况下，2941908.）这应该显示你irssi和pipe道另一端的任何进程。
如果pipe道没有另一端…呃，我不确定。 也许从开始直到问题发生的一个过程，并找出pipe道上发生了什么。 用'-e trace ='标志限制输出可能是有意义的，但是我想不出一套好的东西来限制我的头顶。