Есть ли такие ошибки, зарегистрированные CentOS где-нибудь, которые могут убедительно показать, что "пришло время платить за ECC"
У меня 32 ГБ выделенный сервер без ECC RAM с CentOS.
Один раз в день он случайно вылетает без ошибок в /var/log/kern.log, /var/log/messages, mysql, apache.
Процессор /RAM/IO не особенно высокий или низкий.
Есть ли какая-либо такая ошибка, зафиксированная CentOS где-нибудь, которая может убедительно показать, что "пришло время платить за ECC"?
3 ответа
Что бы вы хотели это войти? CentOS не может знать, что содержимое не-ECC памяти стало поврежденным, потому что это невозможно узнать; он может только знать, что содержание памяти не имеет смысла, и паниковать на основании какой-либо самосогласованности, которую он обнаружил. Это несоответствие могло быть вызвано повреждением ОЗУ, но также могло быть вызвано ошибкой ядра или какой-либо другой причиной.
Единственный способ окончательно узнать, что память стала поврежденной, - это использовать память, которая явно включает поддержку для проверки такого повреждения; остроумие, память ECC.
Изменить: это совершенно другой вопрос, чем тот, который вы задали. Но моя стратегия была бы: беги memtest86+ на оборудовании, чтобы увидеть, есть ли какие-либо легко обнаруживаемые повторяющиеся ошибки, и включить удаленный syslogна сервере (например, когда ядро паникует, оно часто прекращает запись в ФС, но все еще может выдавить сообщение журнала из NIC), чтобы посмотреть, что вошло в следующую панику.
Память ECC имеет два преимущества:
- Он зарегистрирован, что означает наличие регистра перед другими компонентами на чипе. Это должно снять электрическую нагрузку с контроллера памяти. Это относится ко всем RDIMM, а не только к ECC RAM.
- Он может обнаруживать ошибки, а если не исправить, по крайней мере, сообщить, что они произошли
Учитывая это, на самом деле очень трудно определить, выиграли бы вы от оперативной памяти ECC, не имея оперативной памяти ECC. По определению вы не можете регистрировать ошибку при обнаружении ошибки, и у вас, конечно, нет данных о том, была ли ошибка, которая могла произойти, или не произошла, результатом сбоя контроллера памяти.
Тем не менее, если вы запустите memtest, вы определите пару вещей. Если вы не обнаружите ошибок, вам нужна либо ECC RAM, либо проблема в чем-то другом (поэтому, если вы исключаете абсолютно все компоненты аппаратного и программного обеспечения в качестве причины, вы показали необходимость в ECC RAM). Если вы обнаружите постоянные ошибки, скорее всего, ОЗУ плохое и его просто необходимо заменить. Если вы обнаружите несогласованные ошибки, возможно, процессор неисправен или вам может понадобиться ECC RAM. Если вы обнаружите, что memtest86 дает сбой, либо DIMM самого низкого порядка неисправен, либо ЦП неисправен, либо вам требуется ECC RAM.
Несмотря на это, это очень сложно определенно показать. ECC RAM наиболее полезна в приложениях, где невидимые ошибки в расчетах могут вызвать экстремальные проблемы, или в приложениях, где большое количество RAM в сочетании с другими условиями делает ошибки статистически вероятными. Однако сами эти критерии нечеткие и субъективные, поэтому из этого следует, что объективного критерия для этого не существует.
Если где-нибудь, он, вероятно, будет вход
/var/log/mcelog
(это где критические события процессора идут на разводках RHEL)