Pamięć RAM w serwerze to jeden z najbardziej krytycznych elementów infrastruktury. W środowiskach produkcyjnych (wirtualizacja, bazy danych, systemy ERP, storage, VDI) nawet pojedynczy błąd w pamięci może doprowadzić do niestabilności usług, losowych restartów, uszkodzeń danych albo trudnych do zdiagnozowania „krzaków” w aplikacjach.

Dlatego w serwerach standardem jest ECC (Error-Correcting Code) – czyli mechanizmy wykrywania i korekcji błędów pamięci. W tym wpisie wyjaśniamy:

• co dokładnie robi ECC,

• jakie błędy potrafi korygować,

• czym różni się „corrected” od „uncorrected error”,

• kiedy zobaczysz ECC w logach i gdzie tego szukać,

• oraz co zrobić, gdy zaczynają pojawiać się wpisy o korekcjach.

Wpis jest pisany praktycznie – tak, aby dało się go zastosować w realnym środowisku serwerowym.

1) Co to jest ECC i dlaczego w serwerach jest obowiązkowe?

ECC to zestaw mechanizmów, które pozwalają:

• wykryć błąd w przesyłanych/przechowywanych danych w pamięci RAM,

• a w wielu przypadkach automatycznie go skorygować.

W praktyce ECC chroni przed błędami typu „bit flip” (odwrócenie pojedynczego bitu z 0 na 1 lub odwrotnie). Taki błąd może wystąpić m.in. przez:

• zakłócenia elektromagnetyczne,

• promieniowanie kosmiczne (rzadkie, ale realne),

• problemy z modułem RAM,

• problemy z płytą główną/gniazdami DIMM,

• niestabilne zasilanie,

• zbyt wysoką temperaturę.

W PC często kończy się to „zwykłym crashem”. W serwerze – może skończyć się korupcją danych. Dlatego pamięć serwerowa to praktycznie zawsze ECC RDIMM/LRDIMM/3DS.

2) Jak działa ECC w praktyce

W module ECC przechowywana jest dodatkowa informacja kontrolna (tzw. bity parzystości/kod korekcyjny), dzięki czemu kontroler pamięci może sprawdzić, czy dane są poprawne.

W uproszczeniu:

• SEC (Single Error Correction) – korekcja pojedynczego błędu bitu,

• DED (Double Error Detection) – wykrycie (ale zwykle nie korekcja) błędu podwójnego bitu.

Najważniejsze z perspektywy admina:

• błędy skorygowane (corrected) – serwer działa dalej, ale loguje incydent,

• błędy nieskorygowane (uncorrected) – mogą powodować MCE, panic, restart lub zatrzymanie systemu.

W środowisku produkcyjnym kluczowe jest reagowanie na corrected errors zanim przerodzą się w uncorrected.

3) „Corrected” vs „Uncorrected” – jak to interpretować?

Corrected Error

To sygnał ostrzegawczy. System zadziałał poprawnie: wykrył błąd i skorygował dane.

• jeśli zdarza się pojedynczo i rzadko, nie musi oznaczać awarii, ale warto obserwować,

• jeśli rośnie częstotliwość, często wskazuje na:

  • zużywający się moduł RAM,

  • problem z konkretnym slotem,

  • temperatury/airflow,

  • niestabilność platformy.

Uncorrected Error

To sygnał krytyczny. System nie był w stanie skorygować błędu. Skutki mogą obejmować:

• kernel panic,

• BSOD,

• Machine Check Exception,

• restart serwera,

• ryzyko korupcji danych.

Tu zwykle nie ma dyskusji – trzeba działać natychmiast.

4) Gdzie zobaczysz ECC w logach? Najczęstsze miejsca

W praktyce logi ECC mogą pojawić się na kilku poziomach:

A) Logi sprzętowe / BMC (iLO/iDRAC/IPMI)

Najbardziej wartościowe, bo pokazują zdarzenia z perspektywy platformy (DIMM slot, bank, adres). Często tam zobaczysz wpisy typu:

• Correctable memory error

• Uncorrectable memory error

• DIMM fault / predicted failure

B) System operacyjny

• Linux: logi jądra (MCE), journald/syslog

• Windows Server: wpisy w Event Viewer (np. WHEA)

C) Narzędzia diagnostyczne

W środowisku enterprise często używa się narzędzi vendorowych lub standardowych mechanizmów MCE.

Uwaga: jeżeli serwer ma „predictive failure” na DIMM, warto traktować to poważnie nawet wtedy, gdy system jeszcze działa.

5) Co robić, gdy pojawiają się błędy ECC? Praktyczna procedura

1. Zbierz informacje

• które DIMM? który slot? ile zdarzeń? czy rośnie?

2. Sprawdź temperatury i airflow

• pełna obsada RAM potrafi znacząco podnieść temperatury,

• kurz i zabrudzone radiatory robią różnicę.

3. Zweryfikuj poprawność obsady i typy modułów

• czy moduły są zgodne (RDIMM vs LRDIMM),

• czy obsada kanałów jest zgodna z guide producenta.

4. Test obciążeniowy pamięci

• jeżeli liczba corrected errors rośnie, warto potwierdzić stabilność testem RAM.

5. Wymień moduł (albo przełóż do innego slotu)

• jeśli błąd „idzie za modułem”, winny jest DIMM,

• jeśli zostaje w slocie, winny może być slot/płyta.

6. Nie mieszaj przypadkowych kości
   Dobieraj zgodnie z P/N producenta serwera i parametrami platformy.

6) Dlaczego refabrykowane moduły ECC to rozsądny wybór

W BestMicro od lat sprzedajemy refabrykowane moduły serwerowe ECC i widzimy, że w praktyce liczą się trzy rzeczy:

1. Testy – moduły powinny przechodzić testy obciążeniowe i weryfikację stabilności.

2. Kompatybilność – dobór po P/N (Dell/HPE/Lenovo/Supermicro) i zgodnie z zasadami obsady.

3. Gwarancja – minimum 12 miesięcy, często z opcją wydłużenia.

To jest fundamentalna różnica między refabem z pewnego źródła a losowym używanym RAM z nieznaną historią.

ECC: Podsumowanie

ECC to nie „marketing”, tylko realna warstwa bezpieczeństwa danych i stabilności. Corrected errors są ostrzeżeniem, że platforma już zaczęła ratować Cię przed problemem. Warto reagować wcześniej, zanim pojawią się uncorrected errors i przestoje.

Jeśli chcesz dobrać kompatybilne moduły ECC do swojego serwera albo potrzebujesz pomocy w interpretacji logów (iLO/iDRAC/IPMI/WHEA/MCE) – odezwij się. Nasi inżynierowie pomogą dobrać właściwe P/N i bezpiecznie rozbudować pamięć.