Man kennt das: spontan crashende Rechner haben oft defektes oder schlechtes RAM als Ursache. Auf den NetApp Systemen ist das Problem bedingt durch die Verwendung Chipkill-ECC RAM nicht so gravierend, da bei defekten Zellen einfach einzelne Chips ausgeblendet werden und ECC meistens für die Fehlerkorrektur sorgt, so dass das System einfach weiterläuft.
Aber wenn einfach alles weiter funktioniert, wie merkt man dann, dass man schlechtes RAM („RAMsch“) hat? Das System triggert bei dieser Gelegenheit keinen Autosupport, die bequeme Variante entfällt also auch… Trotzdem hilft der Autosupport in diesem Fall weiter. In der ASUP Mail einfach ‚mal nach „ECC MEMORY SCRUBBER STATS“ suchen (alles groß):
===== ECC MEMORY SCRUBBER STATS =====
Main memory-----------Scrub range: 100000 --> 480000000Current scrub is 0% completeLast full scrub completed at: Thu Oct 8 13:11:22 CEST 2009 Mainmemory ECC errors since last reboot: 492
Die letzte Zeile ist entscheidende Hinweis. Um dann mehr Details zu bekommen, geht man in das CLI und setzt folgende Befehle ab:
Filer> priv set advancedFiler*> memerrCorrectable ECC memory errors:Errors on DIMM 1: 0Errors on DIMM 2: 0Errors on DIMM 3: 0Errors on DIMM 4: 0Errors on DIMM 5: 0Errors on DIMM 6: 0Errors on DIMM 7: 492Errors on DIMM 8: 0Errors on DIMM 9: 0Errors on DIMM 10: 0Errors on DIMM 11: 0Errors on DIMM 12: 0Errors on DIMM 13: 0Errors on DIMM 14: 0Errors on DIMM 15: 0Errors on DIMM 16: 0Multiple errors at the same address; replace DIMM 7 soon.
Und so sieht man dann, dass in diesem System DIMM7 ausgetauscht werden sollte.
Frohes Durchforsten der ASUPs… 😉
