Statistiques sur les dysfonctionnements de la RAM

Quelqu'un connaît-il des statistiques ou des études sur la fréquence des dysfonctionnements de la RAM sur les ordinateurs?

Mise à jour: mon ordinateur va bien! Je n'ai pas de problèmes de RAM, je m'intéresse aux statistiques. Je reçois des rapports de bogues pour mon logiciel pour lesquels une cause pourrait être un dysfonctionnement de la RAM sur l'ordinateur de l'utilisateur, et je voudrais savoir quelle est la probabilité.

Merci!

Carl

Dans une population de machines de classe 36 de serveur, je vois une défaillance corrigible détectée par les circuits ECC une fois tous les 3 mois.

Si vous soupçonnez une défaillance de la mémoire, vous devriez exécuter memtest86, qui est inclus avec à peu près toutes les distributions Linux populaires de nos jours.

D'après les taux d'erreur DRAM de Robin Harris : Nightmare on DIMM street :

Une étude de deux ans et demi sur la DRAM sur des dizaines de milliers de serveurs Google a révélé que les taux d'erreur DIMM sont des centaines à des milliers de fois plus élevés que prévu - une moyenne de 3 751 erreurs corrigibles par DIMM par an.

Harris cite une étude réalisée sur 2,5 ans sur la flotte de serveurs de Google . Notez que les serveurs utilisent généralement la RAM EEC, qui effectue une correction d'erreur. Les ordinateurs grand public n'en ont généralement pas.

Berke Durak de Lambda Diode calcule :

Tout d'abord, supposons que vous ayez un système sans correction d'erreur ni parité. La probabilité que vous rencontriez une erreur de bit pendant le temps T sera de 1- (1-p) ^ m.

Pour T = 1 heure, p = 1,3e-12 et m = 4 * 2 ^ 30 * 8 ce qui donne 0,044 ou 4,4%. C'est une probabilité assez élevée. En effet, en une journée, cela conduit à une probabilité de 66% et en 72 heures à une probabilité de 96%.

La probabilité d'avoir au moins une erreur de bit dans 4 gigaoctets de mémoire au niveau de la mer sur la planète Terre en 72 heures est donc supérieure à 95%.

Je ne rirai pas la prochaine fois qu'un collègue dira "rayon cosmique" quand on n'arrivera pas à identifier la cause d'un crash ...

Vous pouvez démarrer l'ordinateur avec memtest86 + et exécuter une vérification pendant la nuit. Voilà comment je trouve des problèmes.

Oui, j'ai vu des bâtons de mémoire se détériorer là où ils n'échoueraient qu'avec un modèle particulier d'écritures mémoire. Le BIOS de l'ordinateur n'a pas détecté le problème, mais memtest86 l'a trouvé lors d'une exécution nocturne.

J'ai vu deux bâtons de RAM se détériorer sur une cinquantaine d'ordinateurs que j'ai utilisés au cours des dix dernières années. Cela arrive, mais pas souvent.

Vous voudrez peut-être jeter un œil à cette étude google :

En moyenne, environ un serveur Google sur trois a rencontré une erreur de mémoire corrigible chaque année et un sur cent une erreur non corrigible

Mais ils parlent de RAM ECC, pas de votre RAM utilisateur quotidienne

J'ai vu une poignée de modules de mémoire tomber en panne sur les serveurs opérationnels au cours de la dernière décennie et un nombre légèrement plus élevé d'échecs lors de la gravure de Memtest86 dans les tests sur le matériel nouvellement livré. Ce sont des systèmes serveurs, dont presque tous auront une mémoire ECC d'une sorte ou d'une autre, je m'attends donc à des problèmes beaucoup plus fréquents sur les systèmes clients avec une RAM sans correction d'erreurs. Je n'ai cependant pas un énorme échantillon d'échantillons à travailler, nous avons quelques dizaines de serveurs et en termes de mise en service des systèmes clients, je dirais que j'ai travaillé sur une centaine à un niveau où je ' Je fais en fait attention à la RAM.

Du côté client, j'ai un peu plus d'expérience à l'échelle de l'entreprise - j'étais ingénieur principal pour un groupe gérant des PC de 50 000 utilisateurs finaux pendant quelques années et nous n'avons jamais vu les pannes matérielles ou logicielles de RAM comme un problème important, ce n'était certainement pas le cas quelque chose qui a affecté un pourcentage mesurable des systèmes. Cela ne veut pas dire que cela ne s'est pas produit, mais je serais très surpris si c'était un problème qui affectait> 1% des ordinateurs de bureau et des ordinateurs portables de classe affaires. Certains modèles spécifiques présentaient des taux d'échec très élevés liés au contrôle de qualité de la construction, le premier lot d'IBM Thinkpad T30 avait un problème avec leur deuxième emplacement DIMM qui nous a obligés à réparer / remplacer quelques milliers de machines à un moment donné.

Ce billet de blog de Larry Osterman de Microsoft de 2005 pourrait cependant fournir une explication à certains d'entre eux - son analyse de certaines erreurs étranges signalées dans l'ensemble de données assez volumineux provenant du rapport d'erreurs Windows indique que bon nombre de ces problèmes étranges sont causés par pointage. Si un nombre important de vos utilisateurs finaux sont susceptibles d'utiliser un kit de niveau grand public cadencé, cela peut être lié à vos erreurs.

Avez-vous la possibilité d'utiliser la `` mémoire en miroir '' dans votre système - cela vous dirait si vous avez des problèmes de mémoire ou non - avec cela en place, il y a BEAUCOUP moins de chances que des erreurs soient dues à des problèmes de mémoire physique.

Si vous utilisez Linux:

Si vous ne voulez pas redémarrer dans memtest86 +, vous pouvez obtenir des résultats en exécutant memtester pour tester la mémoire pour savoir si elle est défectueuse ou non. Il fait un bon travail réaliste pour trouver les défauts irréguliers ainsi que les défauts non déterministes. Il a plusieurs tests pour attraper la limite de la mémoire et produit un rapport détaillé des défauts localisés, des tests exécutés et du temps nécessaire pour trouver les défauts dans l'ordinateur. Pas besoin de redémarrer, vous pouvez l'exécuter sur un système Linux en cours d'exécution.

Je n'ai trouvé aucun lien pour l'application mais voici les informations sur le paquet debian :