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