В чем может быть ошибка в логах по ОЗУ на сервере?

Question

[zslipfanz]

Коллеги, доброго дня! Испытав все варианты, которые были на опыте, обращаюсь к вам за подсказкой. Ситуация такая:

Сервер dell r540 с 384гб ОЗУ на нем развернуто HYPER-V, там крутятся виртуалка с SQL сервером, сервер 1С предприятия и пара терминальных ферм, на самом хосте ничего кроме hyper-v не развернуто. Сервер стал уходить в ребут (приоретно по ночам - смотрел регламентные, ничего на эти часы не назначено), поехали с сис админом смотреть логи и аппаратную диагностику делать - попробовали запуски с выключенными виртуалками, оставляли по одной планке и поэусперементировали с разными слотами - все равно сыпется, собрали обратно, обновили BIOS до последней версии параллельно вместе с прошивкой raid контроллера, запустили тестирование памяти - выявились модули с ошибками, их извлекли, запустили сервер, думали все прошло - но через час посыпались логи снова. Запустили повторный тест - ошибка даже в пустых слотах осталась + добавилась на часть тех, которые были при первом тесте без ошибок. Самое, что интересное, когда запускаешь утилиту тестирования DELL - она запускает общее тестирование всех модулей и на тестировании памяти сыпятся ошибки. После прохождения тестирования, есть возможность оттестировать каждый модуль поотдельности - и вот на тестировании отдельно памяти ошибок нет и результат "успешное тестирование" с зеленым индикатором исправного оборудования.

Вчера перезагрузили сервер (так как бдос вылетел очередной) - сутки ошибки не было, сегодня посыпалась снова. Тайминги бдоса при ошибках разные, может через 5 минут вылететь после запуска, может сутки отработать, может через час - хаотично.

Ошибка:
A corrected hardware error has occurred.

Component: Memory
Error Source: Corrected Machine Check
Error Type: Single-Bit ECC

The details view of this entry contains further information.

Ошибка:
A corrected hardware error has occurred.

Component: Memory
Error Source: Corrected Machine Check
Error Type: 13

The details view of this entry contains further information.

Подскажите, кто может сталкивался/может еще у кого какие теории есть проверить?

Comments

[VoidVolker]

Протестируйте все планки памяти стандартным долгосрочным memtest с лайв флешки, но на другой машине. Если покажет, что планки исправны - среди подозреваемых останутся процессор, материнская плата и блок питания. Хорошо бы протестировать проц на другой машине, а мать с другим процем.

[ReSupport]

Ситуация похожа на то, что сервер не справляется с емкостной нагрузкой, когда установлены сразу все модули памяти. По-хорошему, нужен ремонт. Как компромиссный вариант, можно попробовать правильно подобрать модули.

Answer 1

[Zettabyte]

Error Source: Corrected Machine Check

Вот это говорит, что ошибка была скорректирована. У вас ведь наверняка ECC-память установлена?
Из-за таких ошибок вылетов быть не должно.

Дальше вопрос в том, память какого производителя установлена. Все ли модули одинаковые?
Я встречал ситуации, когда железо крупных вендоров странно определяет некоторые модули (выделялся Hynix). При этом для каких-то случаев обновление BIOS / BMC помогало, т.е. они что-то добавляли.

Проверьте: есть ли ваша память в списке проверенного железа от Делл.
Если есть возможность, проверьте как всё будет работать с гарантированно совместимой памятью.

может еще у кого какие теории есть проверить?

С процессором проверьте не работает ли он по умолчанию в режиме разгона (такое тоже однажды встречалось), и подаётся ли на него достаточное напряжение.

Сервер стал уходить в ребут (приоретно по ночам

Это тоже подсказка, пересекающаяся с идеей выше: попробуйте в БИОС отключить энергосбережение ЦПУ. Оно же может называться отключением (минимализацией) idle states или каким-нибудь max performance mode.

Также разные странные баги могут вылезать после включения защиты от уязвимостей в духе Spectre и Meltdown (отсюда же, кстати, может быть и разгон). Но это уже не самая свежая история, так что вероятность низкая.

Comments

[hint000]

Вот это говорит, что ошибка была скорректирована. У вас ведь наверняка ECC-память установлена?
Из-за таких ошибок вылетов быть не должно.

Но если за раз больше одного бита сбойнуло, то исправление через ECC невозможно и вполне могут быть вылеты (в таком случае, конечно не будет слова Corrected в логах).

[zslipfanz]

Память установлена с поддержкой ECC одного производителя - маркировка Dell, но сам завод как понимаем не Dell, сторонних производителей не рассатривали при сборке. С сервером ничего не делали, кроме физического обслуживания, но накануне сбоев никаких работ не проводилось, поэтому ошибки конфига маловероятны, на всякий случай проверим, будем гонять память memtest'ом на другой машине.. Уже просто варианты закончились, если честно... До этого были похожие симптомы, тоже уходил в ребут непредсказуемо, но тогда на одной из машин Hyper-V была повреждена папка Temp пользователя, под которым запущен сервер 1С предприятия и он при попытке записать в эту папку угонял в ребут весь Host.. сейчас все папки целые, проверяли, думали может в этой проблема повторилась..

[Игорь]

подмахнуть память с другого сервера, если ошибка повторится то imho это глючит железо сервака, если нет то память... я даж не знаю, гарантия вообще работает сейчас?

[zslipfanz]

Игорь, не работает( даже поддержка на связь не выходит, как ранее можно было удаленно проконсультироваться со знанием ломанного английского и диктофоном. Сегодня стартуем ночью тестировать с другой памятью, а эту на другой машине запускать по одной-две планки мем тестом.. Я еще думал в сторону софта, виртуалка с Hyper-V же отправляла в ребут всю машину, может еще где-то что-то поврежденное из папок, но она должна активно использоваться для записи - либо темпы, либо кеши, либо скулевские файлы, может сталкивался кто - какие на какие папки попадали?) если нет, то делюсь опытом

[Zettabyte]

hint000,

Но если за раз больше одного бита сбойнуло, то исправление через ECC невозможно и вполне могут быть вылеты (в таком случае, конечно не будет слова Corrected в логах).

Всё верно. Но раз автор не упоминает uncorrected errors, то я решил, что их и не было.

zslipfanz,

Память установлена с поддержкой ECC одного производителя - маркировка Dell

Если вы полагаете, что с этим порядок, проверьте остальные варианты из ответа выше.

будем гонять память memtest'ом на другой машине

Вот это, кстати, интересно: если ошибка скорректируется с помощью ECC, как в вопросе, увидит ли Мемтест такую проблему?

была повреждена папка Temp пользователя, под которым запущен сервер 1С предприятия и он при попытке записать в эту папку угонял в ребут

А с накопителями-то всё нормально?
Если что, для проверки у нас есть вот такая программа. Но она для запуска в host OS, откуда видны физические диски.

[zslipfanz]

Zettabyte,

А с накопителями-то всё нормально?
Если что, для проверки у нас есть вот такая программа. Но она для запуска в host OS, откуда видны физические диски.

А она работает в обход рейд контроллера? По-моему, там так не выйдет... запустил прогу проверить - вместо дисков отображается котроллер

[Zettabyte]

zslipfanz, Проглядел ваш ответ, только сейчас, в выходные заметил :-|

А она работает в обход рейд контроллера?

Только если контроллер есть в списке поддерживаемых. Мы постепенно добавляем новые, но процесс совсем небыстрый, т.к. программа нацелена на работу с железом "напрямую", в обход винды.

запустил прогу проверить - вместо дисков отображается контроллер

Да, в таком случае только в режиме HBA есть возможность, увы. На боевой машине с переключением, пожалуй, лучше не экспериментировать.

Я выше написал "откуда видны физические диски", но судя по всему, стоило этот момент развернуть пошире.

[zslipfanz]

Zettabyte, собственно, пока был неработоспособен боевой сервер, раскидали всех на резервы и тестили разными способами, ошибка сыпалась, сервер уходил в ребут, пока основная база данных не ушла в режим подозрительная, далее сервер 4 дня работал без ребутов, но ошибка все равно отстреливала в логах, я начал искать другие теории, потому что, если бы память была битой - он бы уже ушел в себя, нагрузку с него не снимали, дополнительные БД так и продолжали крутиться.

И тут я на 4й день думаю, а не нагрузить ли его основной БД и восстановить ее из бекапа. На 20% восстановления все рухнуло, после 4 суток работы. Я полностью удалил эту БД из SQL, форматировал диск, создал новую БД и накатил на нее бекап, все это время не было ни одной ошибки из первого поста.. В ночь запустил тестирование и исправление БД, тоже прошло, в 8:25 утра выскочила

A corrected hardware error has occurred.

Component: Memory
Error Source: Corrected Machine Check
Error Type: Single-Bit ECC

The details view of this entry contains further information.

И пока не появлялось.. я думаю, ребут вызывается либо из-за ошибок по диску, хотя тестирование не выявило ничего, либо некорректной работой самой виртуалки, но пока все работает как часы. Планирую ночью с резервов перевести все на боевую машину и еще раз запуститься.

[Zettabyte]

zslipfanz,

В ночь запустил тестирование и исправление БД, тоже прошло, в 8:25 утра выскочила

Правильно я понимаю, что нагрузка не сервер закончилась, и в нерабочие часы снова ошибка?

Если да, то перечитайте целиком мой изначальный ответ. В таком случае самое время проверить мою идею о нехватке питания на процессоре через отключение экономии, idle, либо подобного.

[zslipfanz]

Правильно я понимаю, что нагрузка не сервер закончилась, и в нерабочие часы снова ошибка?

На основную БД с наибольшим объемом - закончилась, но БД 1С конфигураций Бухгалтерия и ЗУП (общее количество 16 БД) в данное время как раз очень активно использовались.
Питание стоит по схеме a/b, режимов энергосбережения ни в биосе, ни в windows включено не было. Просто до удаления базы с диска и его форматирования ошибка сыпалась с периодичностью 5-15 минут, а сейчас 1 раз за сутки работы

[zslipfanz]

Zettabyte, накатили боевую бд обратно, сервер был включен, но резко перестал реагировать на команды - через rdp не впускал пользователей, просто черный экран. Через idrack на команду ctrl alt del пытался открыть окно авторизации, но не смог... Пришлось ребутать, ошибок никаких по логам не было, спустя 20 минут работы ребутнулся сам с 41 ошибкой, с тех пор работает 3 часа. Аномалия на аномалии... напрашивается снос всей системы и установка заново, чтобы ее исключить... sfc /scannow ошибок не обнаружила, но что-то подсказывает, что они есть

[hint000]

zslipfanz,

напрашивается снос всей системы и установка заново

Продолжаете программными методами сражаться с явно аппаратными проблемами (питание, чипсет, оперативка)?
Ладно.

У меня основное подозрение всё-таки на планки оперативки. Но и версии коллег насчёт питания или материнки считаю вполне обоснованными.

[Zettabyte]

zslipfanz,

режимов энергосбережения ни в биосе, ни в windows включено не было

ОК, если бы в BIOS был бы пункт в духе "Max performance", я бы попробовал его включить, но тут уже оставлю на ваше усмотрение, полагая, что вы знаете что делаете.

сервер был включен, но резко перестал реагировать на команды - через rdp не впускал пользователей, просто черный экран. Через idrack на команду ctrl alt del пытался открыть окно авторизации, но не смог...

Если, как писали выше, вы уже попробовали работу с другими планками памяти, и ошибки остались, то я соглашусь с hint000 - продолжайте методом исключения перебирать железо.

Мне видится околопроцессорная проблема - на десктопных машинах баги, похожие на описанное вами, возникают в т.ч. при вздутии конденсаторов в обвязке ЦПУ на материнской плате.

[zslipfanz]

Zettabyte, парадокс, что я убираю основную базу на резервный сервак - и это чудо живет по нескольку дней (хотя тестовые базы, с такой же конфигурацией, что и основная, причем их 4 штуки работают стабильно с такой же нагрузкой), не могу зависимость уловить, но возможно простое совпадение, поэтому аппаратную часть не беру в расчет, тем более тесты внутренней утилитой проходили и ничего не было выявлено. Последняя софтовая история запланирована на полный снос оси и разворачиванием новых виртуалок. Если после нее будет вылетать, то почетно назову его

Гагарин

и отдам железячникам на полную диагностику, пусть исследуют плату, контроллер и сопутствующие устройства..

[hint000]

zslipfanz,

парадокс, что я убираю основную базу на резервный сервак - и это чудо живет по нескольку дней

У меня был парадокс примерно в 2004 году на ПК. WindowsNT или Windows2000 вылетала в BSOD то через минуту, то через час после загрузки, несколько попыток переустановки WindowsNT или 2000 завершались ошибками. При этом Windows98 SE работала стабильно хоть целый день, с любым прикладным ПО. Причина - Athlon со сколом на углу кристалла.

[zslipfanz]

hint000, ну вот на выходных каждые 1.5-2 часа он улетал ребут, ночью перенесли базу на резервный - с 23:00 работает без отключений.. как объяснить не знаю.. Причем народ на выхах также активно работал, как и сейчас.. Программисты тестовые базы максимально грузят, 8 хугалтерских и 8 зуповский конфигураций активно используются, ошибок никакх нет..

Как только вернем основнуб БД обратно, сразу же через 2 часа улетает

[hint000]

zslipfanz, Не зря MemTest86(+) гоняет по оперативке так много разных паттернов (завораживающее зрелище; говорят, можно бесконечно смотреть, как течёт вода, как горит огонь, и как работает MemTest). Косяки памяти бывают оч-ч-чень хитрые, не выявляемые тупой записью всех нулей и всех единиц.
1) Сбой в ячейке памяти может проявляться только при определённом сочетании битов в ячейке;
2) сбой в ячейке может проявляться только при определённом сочетании битов в этой и в соседней ячейке (даже если сама по себе соседняя ячейка не сбойная), например, совпадающие или противоположные биты в соседней ячейке;
3) сбой в ячейке может проявляться только при смене одного набора битов на другой набор и не проявляться при других изменениях значений;
4) какие-то ещё более странные зависимости...
Ну и, наверное, слышали про технику эксплуатации Rowhammer, появившуюся 10 лет назад.
https://en.wikipedia.org/wiki/Row_hammer
https://habr.com/ru/companies/1cloud/articles/252991/

А теперь на секундочку представьте: вы ведь не контролируете, какие конкретно куски оперативки выделяет гипервизор для виртуалки, далее вы не контролируете, какие конкретно куски оперативки уже гостевая операционка выделяет СУБД и какие из них СУБД выделяет конкретным БД. Определённый набор байтов, попадающих в определённые ячейки при запуске боевой БД может вызывать сбой в ячейках хостовой операционки (но это сбой на уровне железа, а не софта), при этом тестовые БД могут не иметь такого набора байтов, вызывающего сбой, либо распределение памяти происходит иначе и этот набор байтов попадает в другую (более здоровую) часть оперативки.

[zslipfanz]

hint000, мем тест - да) 8гб за 2:40 откатал.. будем ставить по 64гб за одно тестирование, посмотрим, что нагоняет, если все тщетно будет и тесты пройдут успешно, то в эту русскую рулетку я проиграл :D

[Zettabyte]

hint000,

У меня был парадокс примерно в 2004 году на ПК. WindowsNT или Windows2000 вылетала в BSOD то через минуту, то через час ... Windows98 SE работала стабильно хоть целый день ... Причина - Athlon со сколом на углу кристалла

У 98-й, из-за ДОСа под капотом, инструкций было меньше - они все в центре кристалла помещались и до края не доставали :)