Обычные системные сбои на рабочей станции 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, echoback делает паузу в течение не отвечающего времени, но перехватывает, когда снова начинает отвечать, очевидно, без потери ввода, просто лаг.

• 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.

Есть идеи?