У меня есть виртуальная машина Debian, которую я использую на сервере ESX4.0. На этой виртуальной машине размещается несколько пользователей, каждый из которых запускает сеанс irssi внутри экземпляра экрана.
Это работает неплохо, за исключением одного пользователя. По какой-то причине этот сеанс irssi продолжает достигать пика при 100% загрузке ЦП (при этом продолжает работать нормально). Он не запускает никаких сценариев, которые не загружены в других сеансах irssi, которые ведут себя более разумно.
100% ЦП запускается не сразу, а обычно в течение нескольких часов после запуска. Это никогда не уходит.
Как бы вы отладили источник этой проблемы? Я попытался использовать на нем strace и не увидел ничего очевидного, хотя, безусловно, существует другой шаблон для вызовов в начале и после пика.
Для начала вот гистограмма звонков за 30 секунд:
time: 334
gettimeofday: 317
poll: 122
read: 9
write: 2
restart_syscall: 1
Как только ЦП начинает привязку, я получаю следующее:
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
Что мне не хватает? Какой следующий шаг к решению этой проблемы?
Я думаю, вам нужно разобраться, что он так много читает и опрашивает. Поскольку он не открывает и закрывает новые файлы постоянно - по-видимому, только два каждые 30 секунд - lsof должен вам об этом сказать.
Если он читает () из канала, как здесь:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
irssi 4993 user 5w FIFO 0,6 2941908 pipe
затем запустите lsof от имени root для всех процессов и grep для канала, либо имя именованного канала, либо номер узла безымянного канала в его выходных данных. (В данном случае 2941908.) Это должно показать вам irssi и любой процесс, находящийся на другом конце канала.
Если у трубы нет другого конца… я не уверен. Возможно, настройте один из процессов от начала до тех пор, пока не возникнет проблема, и выясните, что происходит с конвейером. Возможно, имеет смысл ограничить вывод флагом '-e trace =' до strace, но я не могу придумать хороший набор вещей, которыми можно было бы ограничиться.