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

Нет.

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

Выполнение этого с механическими жесткими дисками даст некоторые результаты, но с оперативной памятью это не повлияет. Природа компонента такова, что факторы окружающей среды и возраст с гораздо большей вероятностью могут быть причиной сбоев, чем считывание и запись в ОЗУ (даже при максимальной пропускной способности в течение нескольких часов или дней).

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

Я нашел документ Кингстон подробно описывает, как они работают с серверной памятью, я полагаю, что этот процесс, как правило, будет одинаковым для большинства известных производителей. Микросхемы памяти, как и все полупроводниковые устройства, следуют определенной схеме надежности / отказа, которая известна как кривая ванны:

Время представлено на горизонтальной оси, начиная с заводской отгрузки и продолжаясь через три различных периода времени:

• Сбои в раннем периоде жизни: большинство сбоев происходит на раннем этапе использования. Однако с течением времени количество отказов быстро уменьшается. Период отказа в раннем периоде жизни, показанный желтым, составляет примерно 3 месяца.

• Срок службы: в этот период крайне редко случаются сбои. Срок полезного использования показан синим цветом и оценивается в 20+ лет.

• Отказы в конце срока службы: в конце концов, полупроводниковые изделия изнашиваются и выходят из строя. Срок службы отображается зеленым цветом.

Теперь, потому что Кингстон отметил, что в течение первых трех месяцев будет наблюдаться высокая частота отказов (по истечении этих трех месяцев установка считается исправной, пока через 15–20 лет она не выйдет из строя). Они разработали тест с использованием устройства под названием KT2400, которое жестко тестирует сервер модули памяти в течение 24 часов при 100 градусах Цельсия при высоком напряжении, с помощью которых непрерывно проверяются все ячейки каждого чипа DRAM; такой высокий уровень стресс-тестирования приводит к старению модулей по крайней мере на три месяца (как отмечалось перед критическим периодом, когда большинство модулей показывают отказы).

Результаты были:

В марте 2004 г. компания Kingston начала шестимесячное испытание, в ходе которого 100% памяти сервера было протестировано в KT2400. За результатами внимательно следили, чтобы измерить изменение количества отказов. В сентябре 2004 года, после того как все данные испытаний были собраны и проанализированы, результаты показали, что количество отказов сократилось на 90 процентов. Эти результаты превзошли ожидания и представляют собой значительное улучшение для линейки продуктов, которая уже была лидером в своем классе.

Так почему же запись в память бесполезна для памяти сервера? Просто потому, что это уже сделал ваш производитель!

Мы покупаем блейд-серверы и, как правило, покупаем их достаточно большими блоками за раз, поэтому мы получаем их и устанавливаем в течение ДНЕЙ, прежде чем наши сетевые порты будут готовы / защищены. Таким образом, мы используем это время для использования memtest в течение примерно 24 часов, иногда дольше, если он длится в выходные дни - как только это будет сделано, мы распыляем базовый ESXi, и IP готов для применения его профиля хоста после запуска сети. Так что да, мы тестируем его, скорее по возможности, чем по необходимости, но до сих пор он обнаружил несколько модулей DIMM DOA, и это не я делаю физически, поэтому это не требует от меня усилий. Я за это.

Думаю, это зависит от ваших процессов. Я ВСЕГДА запускаю MemTest86 в памяти перед тем, как поместить его в систему (сервер или как-то иначе). После того, как вы настроили и запустили систему, решить проблемы, вызванные неисправной памятью, будет сложно.

Что касается собственно «стресс-тестирования» памяти; Мне еще предстоит понять, почему это может быть полезно, если вы не проводите тестирование для разгона.

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

Лично я похож на вас в том, что частота ошибок ECC для меня более полезна - при условии, что ОЗУ не является DOA, но тогда вы все равно это знаете.

Для оперативной памяти без ECC, запускающей 30 минут на memtest86 +, полезно, поскольку обычно нет надежного метода обнаружения битовых ошибок во время работы системы.
Синий экран не считается надежным методом ...
И слегка нестабильная ОЗУ часто не отображается сразу, только после того, как система обнаружила некоторую полную загрузку памяти, и только тогда, если данные в этой ОЗУ были кодом, который использовался, а затем разбился. Повреждение данных может оставаться незамеченным в течение длительного времени.

Для оперативной памяти ECC он не будет делать ничего, что не будет делать сам контроллер памяти, поэтому в этом нет смысла. Это просто пустая трата времени.

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

Это зависит.

Если вы развертываете 50 000 новых ОЗУ и знаете, что это конкретное оборудование имеет коэффициент отказов 0,01% после работы менее суток, статистически говоря, должно быть несколько из них, которые выйдут из строя в первый же день. Ожоги предназначены для того, чтобы поймать это. При развертывании такого масштаба ожидается отказ, а не исключительная ситуация.

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

Для одного сервера это потенциально пустая трата времени, в зависимости от контекста.

Но если вы устанавливаете 2000 серверов за раз и не выполняете действительный «стресс-тест», вы почти наверняка найдете один сервер, который ведет себя плохо. И это не только для ОЗУ, это для сети, ЦП, жесткого диска и т. Д. Когда вы заменяете один модуль DIMM, это тоже хорошо, просто чтобы быть уверенным, был заменен правильный модуль DIMM (иногда это не вы заменяете DIMM) , поэтому запуск стресс-теста покажет, исправлено оно или нет.

По моему опыту работы с крупномасштабным кластером, HPL - хороший инструмент, чтобы понять, есть ли у вас ошибка DIMM. И моноузловой HPL достаточно, но и более крупный HPL тоже может помочь. Если система ведет себя так, как ожидалось, и не выдает ошибку MCE, которую Linux улавливает в журналах, тогда все в порядке!