Регулярные сбои системы на рабочей станции RHEL5

У меня есть рабочая станция RHEL5, которая недавно начала "икать". Примерно каждые тридцать секунд он, по-видимому, полностью прекращает выполнение примерно на 4 секунды. Вроде бы в этот период ничего не запускается. Долгосрочные процессы, кажется, догоняют их ввод, но новые процессы просто не запускаются.

Конкретные примеры:

• У меня этот цикл работает в оболочке:

  while date; do
     sleep 0.2
  done
  

  Вывод просто пропускает недостающие секунды:

  Fri Aug 13 15:20:29 EDT 2010
  Fri Aug 13 15:20:29 EDT 2010
  Fri Aug 13 15:20:29 EDT 2010
  Fri Aug 13 15:20:30 EDT 2010
  Fri Aug 13 15:20:30 EDT 2010
  Fri Aug 13 15:20:30 EDT 2010
  Fri Aug 13 15:20:30 EDT 2010
  Fri Aug 13 15:20:34 EDT 2010
  Fri Aug 13 15:20:34 EDT 2010
  Fri Aug 13 15:20:35 EDT 2010
  Fri Aug 13 15:20:35 EDT 2010
  Fri Aug 13 15:20:35 EDT 2010
  

• При вводе в терминал, будь то локальная консоль или удаленный через ssh или telnet, эхо-отклик приостанавливается во время отсутствия ответа, но возвращается, когда он снова начинает отвечать, без потери ввода, очевидно, просто задерживается.

• pings остаются без ответа во время отсутствия ответа, но реагируют, когда он возвращается:

  64 bytes from xxx: icmp_seq=1911 ttl=64 time=0.203 ms  
  64 bytes from xxx: icmp_seq=1912 ttl=64 time=0.199 ms  
  64 bytes from xxx: icmp_seq=1913 ttl=64 time=3202 ms  
  64 bytes from xxx: icmp_seq=1914 ttl=64 time=2196 ms  
  64 bytes from xxx: icmp_seq=1915 ttl=64 time=1197 ms  
  64 bytes from xxx: icmp_seq=1916 ttl=64 time=195 ms  
  64 bytes from xxx: icmp_seq=1917 ttl=64 time=0.201 ms  
  64 bytes from xxx: icmp_seq=1918 ttl=64 time=0.206 ms
  

  Это может означать, что он фактически получает ввод в течение периода отсутствия ответа, поскольку эти пакеты ICMP не передаются повторно.

• vmstat 1 вывод тоже задерживается, но не догоняет. Как будто этих нескольких секунд не было. Он также показывает рост ожидающих процессов и спад прерываний и переключений контекста:

  procs -----------memory----------  ---swap-- -----io---- --system-- -----cpu------
   r  b   swpd   free   buff  cache    si   so    bi    bo    in   cs us sy  id wa st
   0  0    132 3111220 305540 588012    0    0     0     0  1035  151  1  1  99  0  0
   0  0    132 3111096 305540 588012    0    0     0     0  1019  125  0  0  99  0  0
   0  0    132 3111220 305540 588012    0    0     0    44  1034  154  0  1  99  0  0
   1  0    132 3111096 305540 588012    0    0     0     0  1016  131  0  0  99  0  0
   6  0    132 3111096 305540 588012    0    0     0     0   417   82  0  0 100  0  0
   0  0    132 3111220 305540 588012    0    0     0     0  1041  155  0  1  99  0  0
   0  0    132 3111096 305540 588012    0    0     0     0  1019  123  1  1  99  0  0
   0  0    132 3111220 305540 588012    0    0     0     0  1032  142  0  1  99  0  0
   0  0    132 3111096 305544 588008    0    0     0    44  1019  134  0  0  99  0  0
  

Перезагрузка на некоторое время решает проблему. В последний раз на то, чтобы вернуться, потребовалось шесть дней. Я не уверен, что это соответствует действительности.

Сначала я подозревал, что проблема может быть связана с модулем видеодрайвера nVidia, но я выключил X Windows и удалил модуль, не изменив симптомов.

В dmesg или / var / log / messages нет ничего, что казалось бы отдаленно актуальным или каким-либо образом совпадало бы с икотой. Похоже, это не проблема с жестким диском, так как я ожидал бы, что iowait будет заметным во время периода отсутствия ответа, если бы это было так, но это не так. Маловероятно, что это проблема с оборудованием, так как икота случается довольно часто. Мне не удалось сократить время до миллисекунд, но это довольно стабильные 30/4/30/4/30/4.

Любые идеи?