debugging irssi usando 100% cpu

Question

Eu tenho uma VM debian em execução em um servidor ESX4.0. Esta VM hospeda um número de usuários, cada um executando uma sessão irssi dentro de uma instância de tela.

Isso está funcionando muito bem, exceto por um usuário. Por alguma razão, esta sessão irssi continua atingindo 100% do uso da CPU (enquanto continua a funcionar normalmente). Não está executando nenhum script que não esteja carregado em outras sessões do irssi que estejam se comportando de forma mais adequada.

A cpu de 100% não começa imediatamente, mas geralmente dentro de algumas horas após o arranque. Isso nunca vai embora.

Como você faria para depurar a origem desse problema? Eu tentei usar strace nele e não vi nada imediatamente óbvio, embora haja certamente um padrão diferente para as chamadas no início, e depois que ele atinge o pico.

No início, aqui está o histograma de chamadas com mais de 30 segundos:

time: 334
gettimeofday: 317
poll: 122
read: 9
write: 2
restart_syscall: 1

Quando a CPU começa a aparecer, eu entendo:

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

Um histograma de 'ltrace -S' do processo de indexação mostra essas como as principais entradas:

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

O que estou perdendo? Qual é o próximo passo para resolver isso?

    

Answer 1

Eu acho que você precisa descobrir o que é ler e pesquisar muito. Já que não está constantemente abrindo e fechando novos arquivos - apenas dois a cada 30 anos, aparentemente - lsof deve te dizer isso.

Se é lido () a partir de um pipe, como aqui:

COMMAND    PID       USER   FD      TYPE             DEVICE     SIZE   NODE NAME
irssi     4993       user    5w     FIFO                0,6         2941908 pipe

execute lsof como root em todos os processos e grep para o pipe, o nome de um pipe nomeado ou o número do nó de um pipe sem nome em sua saída. (Neste caso, 2941908.) Isto deve mostrar-lhe irssi e qualquer processo que esteja do outro lado do canal.

Se o cano não tiver outro fim… não tenho certeza. Talvez traçar um dos processos desde o início até o problema acontecer e descobrir o que está acontecendo com o tubo. Pode fazer sentido limitar a saída com um sinalizador '-e trace =' para strace, mas não consigo pensar em um bom conjunto de coisas para restringir o topo da minha cabeça.