Как исправить “ОШИБКУ: мягкий тупик - CPU#0, застрявший в течение 17163091968 с”?
Я использую 7 в качестве "волшебного" максимального количества. Для меня это - хороший компромисс между пространством, потерянным для дублирования (n этот случай, ~14%) и временем для восстановления (даже если LUN доступен при восстановлении), или размер увеличения, и СВБР.
Очевидно, это работало отлично для меня при работе с 14 дисковыми полками SAN. У двух из наших клиентов было 10 дисковых полок, и магическое количество 7 было сокращено к 5.
В целом, 5-7 работал на меня. Извините, никакие научные данные от меня также, просто испытайте с системами RAID с 2001.
Благодаря всем комментаторам. Я думаю, что нашел ответ. По крайней мере, в сервере версии 2.6.32 30 ядра Ubuntu, кажется, существует ошибка хронометрирования. Ошибка иногда(?) уничтожает машины, когда они достигают времени работы приблизительно 200.. 210 дней. На самом деле останова сразу не происходит после того, как предел достигнут, но инициирован некоторой операцией (в моем случае: apt-get install ...).
NB: 200 дней о 2^32, времена 1/250 второй, и 250 являются значением по умолчанию для CONFIG_HZ.
На данный момент, я не нашел данные по тому, была ли проблема решена в более свежих ядрах. Я знаю, что это, кажется, не влияет на более старое ядро (2.6.32 26 серверов). От всей этой информации я предполагаю, что, если она еще не фиксируется, ею можно избежать:
- загружают машины каждые 190 дней (хорошая идея для обновлений ядра так или иначе)
- корректируют CONFIG_HZ к 100 и таким образом делают его каждые 497 дней. Однако это могло бы иметь довольно неожиданные побочные эффекты, особенно в виртуальных средах. И это не делает , решают проблема.
Вот отчет об ошибках для Ubuntu.
Это - на самом деле ошибка ядра, которая была исправлена следующей фиксацией ядра:
можно искать, LKML для следующего заголовка (не может отправить больше чем 2 ссылки): [стабильные] 2.6.32.21 - связанные с временем работы катастрофические отказы?
И это - ошибка LP#, которая приносит ядро, зафиксируйте:
https://bugs.launchpad.net/ubuntu / + источник/Linux / + ошибка/902317
Обновление до последнего ядра в ясных обновлениях должно устранить эту проблему навсегда.
HTH
Могло случиться так, что хост виртуализации имеет некоторые энергосберегающие функции ("Green IT"), включенная, который мог отправить неиспользованные ядра в низкую мощность/режим ожидания, вызвав интересные разрушения в использовании VMs то ядро? Я услышал, что это раньше было проблемой главным образом в средах HyperV, но это может быть что-то для изучения.
В случае, если кто-то еще находит это, обновление ядра решило подобную проблему для меня. У меня был JBOD, который был присоединен к системе через контроллер SAS3, бросающий их ЦП ошибки Softlock на начальной загрузке.
у меня было версия 3.16.0-30 ядра Ubuntu 14.04.2, и выполнение "способного обновления-y" закончило меня в ядре 3.16.0-49, и это решило проблему.