Est-il nécessaire de graver de la RAM pour du matériel de classe serveur?


31

Compte tenu du fait que de nombreux systèmes de classe serveur sont équipés de RAM ECC , est-il nécessaire ou utile de graver les modules DIMM de mémoire avant leur déploiement?

J'ai rencontré un environnement où toute la RAM du serveur est placée à travers un long processus de rodage / test de stress. Cela a parfois retardé les déploiements du système et impacté le délai de livraison du matériel.

Le matériel du serveur est principalement Supermicro , la RAM provient donc d'une variété de fournisseurs; pas directement du fabricant comme un Dell Poweredge ou HP ProLiant .

Est-ce un exercice utile? Dans mon expérience passée, j'ai simplement utilisé la RAM du fournisseur hors de la boîte. Les tests de mémoire POST ne devraient-ils pas attraper la mémoire DOA? J'ai répondu aux erreurs ECC bien avant qu'un module DIMM ne tombe en panne, car les seuils ECC étaient généralement le déclencheur du placement de la garantie.

  • Brûlez-vous votre RAM?
  • Si oui, quelle (s) méthode (s) utilisez-vous pour effectuer les tests?
  • A-t-il identifié des problèmes avant le déploiement?
  • Le processus de rodage a-t-il entraîné une stabilité supplémentaire de la plateforme par rapport à la non-exécution de cette étape?
  • Que faites-vous lorsque vous ajoutez de la RAM à un serveur en cours d'exécution?

Réponses:


25

J'ai trouvé un document de Kingston détaillant comment ils fonctionnent avec la mémoire du serveur, je pense que ce processus serait, normalement, le même pour la plupart des fabricants connus. Les puces mémoire, ainsi que tous les dispositifs semi-conducteurs, suivent un modèle de fiabilité / défaillance particulier connu sous le nom de courbe de baignoire:

entrez la description de l'image ici

Le temps est représenté sur l'axe horizontal, en commençant par l'expédition d'usine et en continuant sur trois périodes distinctes:

  • Échecs précoces: la plupart des échecs se produisent pendant la période d'utilisation précoce. Cependant, avec le temps, le nombre d'échecs diminue rapidement. La période d'échec de la vie précoce, indiquée en jaune, est d'environ 3 mois.

  • Durée de vie: pendant cette période, les pannes sont extrêmement rares. La durée de vie utile est indiquée en bleu et est estimée à plus de 20 ans.

  • Échecs de fin de vie: les produits semi-conducteurs finissent par s'user et échouer. La période de fin de vie est indiquée en vert

Maintenant, parce que Kingston a noté que des taux d'échec élevés se produiraient au cours des trois premiers mois (après ces trois mois, l'unité est considérée comme bonne jusqu'à sa fin de vie environ 15 à 20 ans plus tard). Ils ont conçu un test à l'aide d'une unité appelée KT2400 qui teste brutalement les modules de mémoire du serveur pendant 24 heures à 100 degrés Celsius à haute tension, par lequel toutes les cellules de chaque puce DRAM sont continuellement exercées; ce niveau élevé de tests de résistance a pour effet de faire vieillir les modules d'au moins trois mois (comme indiqué avant la période critique où la plupart des modules présentent des défaillances).

Les résultats ont été:

En mars 2004, Kingston a entamé un essai de six mois au cours duquel 100% de la mémoire de son serveur a été testée dans le KT2400. Les résultats ont été étroitement surveillés pour mesurer l'évolution des échecs. En septembre 2004, après que toutes les données de test ont été compilées et analysées, les résultats ont montré que les défaillances étaient réduites de 90%. Ces résultats ont dépassé les attentes et représentent une amélioration significative pour une gamme de produits qui était déjà au sommet de sa catégorie.

Alors pourquoi la gravure en mémoire n'est-elle pas utile pour la mémoire du serveur? Simplement, car c'est déjà fait par votre constructeur!


10
Le fabricant de puces, et peut-être même le fournisseur de serveurs, pourraient tester certaines puces. Mais les composants mst ne sont testés que de nos jours pour réduire les coûts. Même si vos puces ou modules DIMM entiers ont été testés une fois, cela ne vous dit pas si les contacts ou le PCB ont été modifiés ou endommagés lors de l'assemblage ou de l'expédition. Nous avons eu un problème de recherche de mémorisation de MemTEst86 avec la mémoire de deux serveurs différents, prêts à l'emploi de deux fournisseurs de serveurs "de niveau 1" différents. S'ils avaient atteint la production, ECC aurait pu nous sauver, mais une corruption de base de données silencieuse aurait également pu en résulter.
rmalayter

7
Cette courbe de baignoire n'est pas réservée aux semi-conducteurs. La plupart des composants construits avec n'importe quel degré de contrôle de qualité le suivent: disques durs, SSD, alimentations (principalement à cause des condensateurs), ventilateurs, etc.
voretaq7

6
C'est l'une des raisons pour lesquelles je n'achète jamais de garanties prolongées sur l'électronique. L'appareil (ou le composant) va soit échouer dans les premiers mois, soit durer le reste de sa vie. Cela démontre également pourquoi il est si important d'éliminer les mauvaises pommes tôt afin de pouvoir naviguer en douceur le plus rapidement possible.
Atari911

@rmalayter Vous préconisez donc de toute façon la gravure de la RAM?
ewwhite

2
@ewwhite Oui, je testerais. Il ne faut que quelques heures pour démarrer memtest86 et le laisser vérifier 384 Go de RAM. Nous brûlons également dans tous les sous-systèmes de stockage en utilisant IOmeter pour la même raison. Plusieurs contrôleurs ou lecteurs RAID sont morts sur nous lors de la gravure au cours des dernières années, même s'ils ont initialement fonctionné correctement lors de l'installation du système d'exploitation. Parfois, c'était un mauvais firmware, parfois une mémoire RAM défectueuse sur le contrôleur RAID, parfois c'était "qui sait - RMA!"
rmalayter

30

Non.

Le but de la gravure dans le matériel est de le stresser au point de catalyser une défaillance d'un composant.

Faire cela avec des disques durs mécaniques obtiendra des résultats, mais cela ne fera pas grand-chose pour la RAM. La nature du composant est telle que les facteurs environnementaux et l'âge sont beaucoup plus susceptibles d'être la cause d'échecs que ne le seraient jamais la lecture et l'écriture dans la RAM (même à sa bande passante maximale pendant quelques heures ou jours).

En supposant que votre RAM est de qualité suffisante pour que la soudure ne fonde pas la première fois que vous commencez vraiment à l'utiliser, un processus de rodage ne vous aidera pas à trouver des défauts.


15

Nous achetons des lames et nous achetons généralement un bloc raisonnablement important à la fois, en tant que tel, nous les obtenons et les installons au cours des JOURS avant que nos ports réseau ne soient prêts / sécurisés. Nous utilisons donc ce temps pour utiliser memtest pendant environ 24 heures, parfois plus si cela dure un week-end - une fois cela fait, nous pulvérisons l'ESXi de base et IP est prêt pour que son profil d'hôte soit appliqué une fois le réseau activé. Alors oui, nous le testons, plus par opportunité que par nécessité, mais il a attrapé quelques modules DIMM DOA avant maintenant, et ce n'est pas moi qui le fais physiquement, donc cela ne me prend aucun effort. J'y suis.


3
Un «test d'opportunité» a du sens - étant donné la chance que je ferais. Si cela va retarder les déploiements, je peux risquer un mauvais
module

2
Si vous intégrez le test dans le plan de déploiement, vous avez gagné du temps, si vous faites tout aussi vite que possible, vous vous exposez à des critiques à une date ultérieure. Une gestion solide chaque fois que vous le pouvez :)
Chopper3

@ Chopper3 Donc, si vous établissiez une politique, faites-le toujours? , n'est-ce jamais? ou le faire quand vous le pouvez? .
ewwhite

@ewwhite - Je dirais ce dernier, bien que nous ayons tendance à intégrer cela dans le plan de déploiement standard, il est donc très probable à chaque fois.
Chopper3

11

Eh bien, je suppose que cela dépend exactement de vos processus. J'exécute TOUJOURS MemTest86 sur la mémoire avant de le mettre dans un système (serveur ou autre). Une fois le système opérationnel, les problèmes causés par une mémoire défectueuse peuvent être difficiles à résoudre.

Quant à la «mise à l'épreuve» de la mémoire; Je n'ai même pas encore vu pourquoi cela serait utile à moins que vous ne testiez à des fins d'overclocking.


Que vous dit MemTest86? Avez-vous rencontré des problèmes de RAM avant de l'installer sur un serveur à l'aide de cette méthode?
ewwhite

4
J'ai trouvé beaucoup d'erreurs avec MemTest86 + que les diagnostics du BIOS et de la mémoire Windows ne trouveront pas. Je le recommande fortement. Oui, ECC trouvera les mêmes erreurs, mais un memtest vous aidera à les trouver toutes à l'avance.
Owen Johnson

6
MemTest vous fera savoir s'il y a des défauts dans les internes de la mémoire. Il le fait en stockant des modèles d'octets ainsi que des ensembles aléatoires d'octets dans la mémoire pour tenter de déclencher une erreur. Le programme peut exécuter une «passe» pour vous faire savoir si la mémoire est bonne, mais j'exécute généralement plusieurs passes pendant la nuit juste pour être sûr. La bonne chose à propos de MemTest est qu'il me dit si la mémoire est mauvaise avant de déployer le système. Cela a déclenché un RMA plusieurs fois et m'a évité beaucoup de maux de tête. Une fois que la machine est déployée, c'est une douleur dans le @ss pour RMA la mémoire.
Atari911

2
@OwenJohnson En général, lorsque vous exécutez MemTest86 (+), vous espérez déclencher ces erreurs ECC avant de mettre la machine en production :-)
voretaq7

6

Non, mais j'ai vu des gens qui le font. Je ne les ai jamais vus en tirer quoi que ce soit, je pense que cela pourrait être une gueule de bois ou une superstition peut-être.

Personnellement, je suis comme vous en ce sens que les taux d'erreur ECC me sont plus utiles - en supposant que la RAM n'est pas DOA mais vous le sauriez de toute façon.


6

Pour un ram non ECC, exécuter 30 minutes sur memtest86 + est utile car il n'y a généralement pas de méthode fiable pour détecter les erreurs de bits lorsque le système est en cours d'exécution.
Le filtrage bleu n'est pas considéré comme une méthode fiable ...
Et la RAM légèrement squameuse n'apparaît pas immédiatement immédiatement, seulement après que le système a vu une charge de mémoire complète et seulement si les données dans cette RAM étaient du code qui a été utilisé et puis s'est écrasé. La corruption des données peut passer inaperçue pendant de longues périodes.

Pour le ram ECC, il ne fera rien que le contrôleur de mémoire lui-même ne fera donc pas vraiment de sens. C'est juste une perte de temps.

D'après mon expérience, les gens qui insistent pour brûler sont généralement de vieux gars qui l'ont toujours fait comme ça et qui continuent de le faire par habitude sans vraiment penser que les choses sont vraies.
Ou ce sont des jeunes gars suivant la procédure prescrite écrite par ces vieux gars.


Mauvaise connaissance, transmise de génération en génération?
ewwhite

@ewwhite Oui, pour autant que je sache. Et j'ai un Bsc. dans la technologie du matériel informatique, donc je suis censé savoir de quoi je parle :-)
Tonny

à l'exception de tous les incidents de personnes qui ont effectivement trouvé des erreurs, comme indiqué dans le fil. De plus, si ce n'est pas évident, il y a une différence à faire échanger les pièces avant de mettre un serveur en production ou de remplacer ram sur un serveur DB qui fonctionne en 24x7. À moins de prétendre que c'est une "erreur de croissance" et que tout le monde est juste vieux et fait des trucs cultes de fret, mais cela va toujours causer des pertes d'avoir un serveur de prod hors ligne.
Florian Heigl

1
@FlorianHeigl Je ne préconise pas la gravure dans la RAM pour le plaisir, mais je n'approuverai jamais la mise en production d'un serveur, sans qu'il soit soumis à des tests de résistance pendant au moins 24 heures. La RAM n'est généralement pas le problème. Disques durs floconneux, contrôleurs RAID, cartes IPMI, alimentations, CPU, VRM ... J'ai tout vu. (Et souvent, le serveur survit très bien à l'installation initiale. C'est la charge et / ou la santé qui le fait quand il doit vraiment fonctionner.)
Tonny

3

Ça dépend.

Si vous déployez 50000 nouvelles RAM et que vous savez que ce matériel particulier a un taux de défaillance de 0,01% après avoir fonctionné moins d'une journée, statistiquement, il doit y en avoir plusieurs qui échoueront le premier jour. Le fait de brûler est censé attraper cela. Avec des déploiements à cette échelle, un échec est prévu, pas une situation exceptionnelle.

Si vous ne déployez que quelques centaines d'articles, les statistiques sont probablement de votre côté, car vous ne devez pas avoir de chance d'obtenir des pièces défectueuses.


Tu marques un point. Btu avouons-le, la plupart d'entre nous ne feront jamais de déploiements aussi importants. (À moins que vous ne construisiez un nouveau centre de données Google.) La plupart d'entre nous déploient généralement au plus 5 à 10 serveurs en même temps. Personnellement, le plus gros que j'ai jamais fait était 16 nœuds ESX (4x clusters à 4 nœuds) qui ont chacun pris 8 modules DIMM. C'était il y a 3 ans et depuis lors, 1 DIMM est tombé en panne (il y a 2 mois). J'ai dû remplacer 5 alimentations sur ces mêmes machines. Déjà 1 après une semaine. Mais comme ce sont des HP Proliants, nous nous attendions à cela. (HP et alimentations .. Ne me lancez pas ...)
Tonny
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.