LINUX.ORG.RU

Влияние выхода из строя планки памяти на ОС

 , ,


0

3

Всем привет.

Есть сервер Fujitsu PRIMERGY RX4770 M3 c 32 EEC модулями памяти 16GB Samsung (M393A2K40BB1-CRC) Операционная система Oracle Linux 7.9 Технологии зеркалирования или спейринга памяти не использовались.

В один из дней планка памяти начала производить корректируемые ошибки. Через некоторое время модуль перешел в режим Error, после чего операционной системе стало плохо. Начался троттлинг ЦПУ и возросла нагрузка на сервер.

В логах самого сервера выглядело это так:

| Sat 30 Jan 2021 14:34:56 PM | Major | 19001A | iRMC S4 | 'MEM3_DIMM-B1': Memory module failure predicted | Memory | Yes |
| Sat 30 Jan 2021 15:25:44 PM | Major | 190033 | BIOS | 'MEM3_DIMM-B1': Too many correctable memory errors | Memory | No |
| Sat 30 Jan 2021 15:25:45 PM | Critical | 190035 | iRMC S4 | 'MEM3_DIMM-B1': Memory module error | Memory | Yes |
| Sat 30 Jan 2021 09:59:37 PM | Major | 190033 | BIOS | 'MEM3_DIMM-B1': Too many correctable memory errors | Memory | No |
| Sat 30 Jan 2021 09:59:37 PM | Major | 190033 | BIOS | 'MEM3_DIMM-B1': Too many correctable memory errors | Memory | No |

в /var/log/messages так:

Jan 30 14:34:55 server1 kernel: mce: [Hardware Error]: Machine check events logged
Jan 30 14:34:55 server1 kernel: EDAC MC2: 213 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 or CPU_SrcID#1_Ha#0_Chan#1_DIMM#1 (channel:1 page:0x3833edc offset:0x0 grain:32 syndrome:0x0 -  OVERFLOW area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:2 rank:255)
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]: It has been corrected by h/w and requires no further action
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]: event severity: corrected
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]:  Error 0, type: corrected
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]:  fru_text: Card03, ChnB, DIMM0
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]:   section_type: memory error
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]:   node: 2 card: 1 module: 0 
Jan 30 14:35:27 server1 kernel: {1}[Hardware Error]:   error_type: 2, single-bit ECC
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]: It has been corrected by h/w and requires no further action
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]: event severity: corrected
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]:  Error 0, type: corrected
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]:  fru_text: Card03, ChnB, DIMM0
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]:   section_type: memory error
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]:   node: 2 card: 1 module: 0 
Jan 30 15:26:39 server1 kernel: {2}[Hardware Error]:   error_type: 2, single-bit ECC
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]: It has been corrected by h/w and requires no further action
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]: event severity: corrected
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]:  Error 0, type: corrected
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]:  fru_text: Card03, ChnB, DIMM0
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]:   section_type: memory error
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]:   node: 2 card: 1 module: 0 
Jan 30 21:59:52 server1 kernel: {3}[Hardware Error]:   error_type: 2, single-bit ECC
Jan 30 22:08:37 server1 kernel: perf: interrupt took too long (34740 > 34456), lowering kernel.perf_event_max_sample_rate to 5000
Jan 30 22:11:54 server1 kernel: perf: interrupt took too long (43438 > 43425), lowering kernel.perf_event_max_sample_rate to 4000
Jan 30 22:15:02 server1 kernel: mce: [Hardware Error]: Machine check events logged
Jan 30 22:15:02 server1 kernel: EDAC MC2: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#3_DIMM#0 or CPU_SrcID#1_Ha#0_Chan#3_DIMM#1 (channel:3 page:0x32bb2cd offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c3 socket:1 ha:0 channel_mask:8 rank:255)
Jan 30 22:18:05 server1 kernel: perf: interrupt took too long (54573 > 54297), lowering kernel.perf_event_max_sample_rate to 3000
Jan 30 22:24:04 server1 kernel: perf: interrupt took too long (68810 > 68216), lowering kernel.perf_event_max_sample_rate to 2000

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

Как я себе это представляю: Модуль памяти какой какой-то причине стал продуцировать корректируемые ошибки памяти. Эти ошибки нормально обрабатывались при помощи ECC, но при достижении определенного количества таких ошибок по каунтеру, сервер решил вывести данный модуль из работы. Я так думаю, потому что если бы он вышел из строя по причине некорректируемой ошибки, то я бы увидел перезагрузку системы. После перехода модуля в режим Error системе стало резко плохо и сервис, который крутился на данном сервере (Oracle DB) по сути встал колом.

Что мне не понятно во всем этом и на что я не смог найти куда копать:

  1. Должна ли ОС корректно отрабатывать такой выход памяти из строя? Почему потеря планки отразилась на работе ЦПУ? Что почитать на тему MCE и вообще как ОС обрабатывает такие сбои?
  2. По какой-то причине планка памяти, которая была сбойной, в другом сервере показывает себя нормально. Означает ли это, что проблема может быть в самом сервере или на уровне контакта памяти и мат.платы, не знаю даже что и думать :)
  3. Может быть я вообще все неправильно понял, с удовольствием послушал бы альтернативное мнение.

если бы он вышел из строя по причине некорректируемой ошибки, то я бы увидел перезагрузку системы

Не обязательно, хотя вполне вероятно.

Должна ли ОС корректно отрабатывать такой выход памяти из строя?

Нет.

Почему потеря планки отразилась на работе ЦПУ?

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

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

Возможно. А возможно, проблема воспроизводится только в окружении первого сервера. Или MemTest просто её не ловит.

Может быть я вообще все неправильно понял,

В ынтерпрайзе ничего понимать и не надо. Видишь ошибки - меняй.

pinus_nigra
()

Ecc reg память бессмысленно гонять мемтестом.

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

zemidius
()

Пыль, окисление контактов, etc. Уже советовали поменять слот и проверить эту планку на нем.

einhander ★★★★★
()

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

anonymous
()
Ответ на: комментарий от ilovewindows

Поставь в другой разъем в этот же комп, будет сбой выбрасывай

Именно так. Приплюсовываюсь.

NHS7
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.