Нужно ли прожигать оперативную память для оборудования серверного класса?
Учитывая тот факт, что многие системы серверного класса оснащены ОЗУ ECC, необходимо или полезно записывать модули DIMM памяти перед их развертыванием?
Я столкнулся со средой, в которой вся оперативная память сервера размещается в процессе длительного прожигания / стресс-тестирования. Это иногда задерживает развертывание системы и влияет на время подготовки оборудования.
В качестве серверного оборудования используется в основном Supermicro, поэтому оперативная память поступает от различных поставщиков; не напрямую от производителя, как Dell Poweredge или HP ProLiant.
Это полезное упражнение? В моем прошлом опыте я просто использовал ОЗУ производителя из коробки. Разве тесты памяти POST не должны перехватывать память DOA? Я реагировал на ошибки ECC задолго до того, как модуль DIMM действительно вышел из строя, так как пороговые значения ECC обычно были триггером для размещения гарантии.
- Вы прожигаете свою оперативную память?
- Если да, то какой метод (ы) вы используете для проведения тестов?
- Выявлены ли какие-либо проблемы перед развертыванием?
- Приведет ли процесс выгорания к дополнительной стабильности платформы по сравнению с не выполнением этого шага?
- Что вы делаете при добавлении оперативной памяти на существующий работающий сервер?
7 ответов
Я нашел документ Kingston, в котором подробно описывается, как они работают с серверной памятью, и я полагаю, что этот процесс, как правило, будет одинаковым для большинства известных производителей. Микросхемы памяти, как и все полупроводниковые устройства, следуют определенной схеме надежности / отказа, известной как кривая ванны:
Время представлено на горизонтальной оси, начиная с заводской отгрузки и продолжаясь в течение трех различных периодов времени:
Сбои в начале жизни: большинство сбоев происходит в период раннего использования. Однако со временем количество отказов быстро уменьшается. Период ранней неудачи, показанный желтым цветом, составляет приблизительно 3 месяца.
Полезная жизнь: в этот период сбои крайне редки. Срок полезного использования показан синим цветом и оценивается в 20+ лет.
Отказы в конце срока службы: в конечном итоге, полупроводниковые изделия изнашиваются и выходят из строя. Период окончания жизни показан зеленым
Теперь, потому что Кингстон отметил, что первые три месяца будут иметь место высокие показатели отказов (после этих трех месяцев устройство считается хорошим, пока его EOL не наступит через 15 - 20 лет). Они разработали тест с использованием модуля под названием KT2400, который жестоко тестирует модули памяти сервера в течение 24 часов при 100 градусах Цельсия при высоком напряжении, с помощью которого все ячейки каждого чипа DRAM непрерывно работают; Этот высокий уровень стресс-тестирования приводит к старению модулей как минимум на три месяца (как отмечалось до критического периода, когда большинство модулей показывают отказы).
Результаты были:
В марте 2004 года Kingston начал шестимесячную пробную версию, в которой 100 процентов его серверной памяти было протестировано на KT2400. Результаты были тщательно проверены, чтобы измерить изменение отказов. В сентябре 2004 года, после того как все данные испытаний были скомпилированы и проанализированы, результаты показали, что сбои сократились на 90 процентов. Эти результаты превзошли ожидания и представляют собой значительное улучшение для продуктовой линейки, которая уже была на вершине своего класса.
Так почему запись в память бесполезна для памяти сервера? Просто потому что это уже сделано вашим производителем!
Нет.
Цель горения в оборудовании состоит в том, чтобы подчеркнуть его до такой степени, чтобы катализировать отказ в компоненте.
Делая это с механическими жесткими дисками, вы получите некоторые результаты, но для оперативной памяти это мало что даст. Природа компонента такова, что факторы окружающей среды и возраст гораздо более вероятны быть причиной сбоев, чем чтение и запись в ОЗУ (даже при максимальной пропускной способности в течение нескольких часов или дней).
Если у вас достаточно высокого качества ОЗУ, чтобы припой не расплавился при первом его использовании, процесс выгорания не поможет вам найти дефекты.
Мы покупаем blade-серверы и, как правило, покупаем достаточно большие блоки за один раз, поэтому мы устанавливаем их и устанавливаем их в течение ДНЕЙ до того, как наши сетевые порты будут готовы / безопасны. Таким образом, мы используем это время, чтобы использовать memtest в течение 24 часов, иногда дольше, если он длится в выходные дни - как только это будет сделано, мы разбрызгиваем базовый ESXi, и IP готов для применения его профиля хоста, как только сеть начнет работать. Так что да, мы тестируем это, скорее из-за возможности, чем из-за необходимости, но до этого момента уловили несколько DOA DIMM, и это не я делаю физически, поэтому мне не нужно никаких усилий. Я за это.
Ну, я думаю, это зависит от того, что именно ваши процессы. Я ВСЕГДА запускаю MemTest86 в памяти, прежде чем поместить ее в систему (сервер или иным образом). После того, как ваша система запущена и работает, проблемы, вызванные неисправной памятью, могут быть трудно устранить.
Что касается собственно "стресс-тестирования" памяти; Я еще даже не понимаю, почему это было бы полезно, если вы не тестируете для целей разгона.
Для оперативной памяти, не поддерживающей ECC, полезно использовать 30 минут на memtest86+, поскольку обычно не существует надежного метода обнаружения битовых ошибок во время работы системы.
Синий скрининг не считается надежным методом...
И слегка нестабильное ОЗУ часто не отображается сразу, только после того, как система увидела некоторую загрузку полной памяти, и только тогда, если данные в этом ОЗУ были кодом, который использовался и затем потерпел крах Повреждение данных может оставаться незамеченным в течение длительных периодов времени.
Для ECC ram он не будет делать ничего, чего не будет делать сам контроллер памяти, так что на самом деле это не имеет смысла. Это просто трата времени.
По моему опыту, люди, которые настаивают на том, чтобы выжигать, - это, как правило, старые парни, которые всегда так делали и которые продолжают делать это по привычке, не думая, что это правда.
Или они молодые парни, следуя предписанной процедуре, написанной этими старыми парнями.
Я не знаю, но я видел людей, которые делают. Я никогда не видел, чтобы они что-то от этого получали, я думаю, что это может быть похмелье или суеверие, возможно.
Лично я, как и вы, в том, что частота ошибок ECC для меня более полезна - при условии, что ОЗУ не DOA, но тогда вы все равно это знаете.
Это зависит.
Если вы развертываете 50 000 новых ОЗУ и знаете, что у этого конкретного оборудования частота отказов составляет 0,01% после менее чем одного дня работы, то, по статистике, должно быть несколько из них, которые выйдут из строя в первый же день. Сжигание предназначено, чтобы поймать это. С развертываниями такого масштаба ожидается сбой, а не исключительная ситуация.
Если вы развертываете только пару сотен элементов, статистика, скорее всего, на вашей стороне, так как вам не повезло, чтобы получить неисправные части.
Для одного сервера это потенциально пустая трата времени, в зависимости от контекста.
Но если вы устанавливаете 2000 серверов за раз и не проводите действительный "стресс-тест", вы почти наверняка найдете один сервер, который ведет себя плохо. И это не только для ОЗУ, это для сети, ЦП, жесткого диска и т. Д. Когда вы заменяете один модуль DIMM, это тоже хорошо, просто чтобы быть уверенным, был заменен правильный модуль DIMM (иногда это не вы заменяете модуль DIMM), поэтому запуск стресс-теста покажет, исправлено оно или нет.
По моему опыту работы с крупномасштабным кластером, HPL - хороший инструмент, чтобы понять, есть ли у вас ошибка DIMM. И моноузловой HPL достаточно, но более крупный HPL тоже может помочь. Если система ведет себя так, как ожидалось, и не выдает ошибку MCE, которую Linux улавливает в журналах, тогда все в порядке!