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 --> 480000000
Current scrub is 0% complete
Last full scrub completed at: Thu Oct 8 13:11:22 CEST 2009 Main
memory 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 advanced
Filer*> memerr
Correctable ECC memory errors:
Errors on DIMM 1: 0
Errors on DIMM 2: 0
Errors on DIMM 3: 0
Errors on DIMM 4: 0
Errors on DIMM 5: 0
Errors on DIMM 6: 0
Errors on DIMM 7: 492
Errors on DIMM 8: 0
Errors on DIMM 9: 0
Errors on DIMM 10: 0
Errors on DIMM 11: 0
Errors on DIMM 12: 0
Errors on DIMM 13: 0
Errors on DIMM 14: 0
Errors on DIMM 15: 0
Errors on DIMM 16: 0
Multiple 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… 😉