RAM故障统计

在服务器类别36的机器人群中，我发现ECC电路每3个月检测一次可纠正的故障。

如果您怀疑内存memtest86 ，那么您应该运行memtest86 ，这些内容几乎包括了所有stream行的Linux发行版。

从罗宾哈里斯的DRAM错误率：在DIMM街道上的噩梦 ：

在数以千计的Google服务器上运行了两年半时间的DRAM研究发现，DIMM错误率比想象的高出数百倍至数千倍 – 平均每个DIMM每年纠正3,751个错误。

哈里斯引用了在Google服务器上运行了两年半的研究 。 请注意，服务器通常使用EEC RAM，执行一些错误更正。 消费级电脑通常没有这个。

Lambda Diode的Berke Durak 计算 ：

首先，让我们假设你有一个没有错误纠正或平价的系统。 在时间T期间您将遇到位错误的概率将是1-（1-p）^ m。

对于T = 1小时，p = 1.3e-12和m = 4 * 2 ^ 30 * 8得到0.044或4.4％。 这是相当高的概率。 事实上，在一天内，这导致了66％的概率，72小时内的概率达到了96％。

因此，72小时内地球上海平面4千兆字节至less有一位误差的概率超过了95％。

我们不会在下次同事说“宇宙射线”的时候，我们不能确定事故原因。

你可以使用memtest86 +启动电脑，并在夜间进行检查。 这就是我发现问题的方法。

是的，我已经看到内存棒坏了，他们只会在一个特定的内存写入模式下失败。 计算机的BIOS没有检测到问题，但是memtest86在一夜之间发现了它。

在过去的十年里，我已经看到了大约五十台电脑中有两支RAM坏了。 它发生，但不经常。

你可能想看看这个谷歌研究 ：

平均而言，每三个Google服务器中就有一个每年经历一次可纠正的内存错误，一次有百分之一的错误无法纠正

但他们在谈论ECC RAM，而不是你的日常用户RAM

在过去的十年左右，我看到less数几个内存模块在运行的服务器上发生故障，而在testing新交付的硬件时，Memtest86烧毁的时候出现了一些故障。 这些是服务器系统，几乎所有这些系统都会有ECC存储器，所以我希望在客户端系统上使用非纠错RAM来解决更多的问题。 虽然我没有一个庞大的样本集，但是我们有自己的几十台服务器，而且在debugging客户系统方面，我会说我已经在一百个左右的工作了， d实际上是在关注RAM。

在客户端，我在企业级有更多的经验 – 我是一个pipe理5万台terminal用户PC几年的高级工程师，我们从来没有看到内存硬件或软件故障是一个重大问题，当然不是影响系统可测量百分比的东西。 这并不是说没有发生，只是如果这个问题影响了大约1％的商务级台式机和笔记本电脑，我会感到非常惊讶。 一些特定的型号会performance出与构build质量控制相关的非常高的故障率，第一批IBM Thinkpad T30的第二个DIMM插槽有问题，导致我们不得不一次性更换几千台机器。

微软公司的Larry Osterman从2005年的这篇博客文章可能会给出一些可能的解释 – 他对来自Windows错误报告的相当大的数据集中的一些奇怪错误的分析表明，许多这些奇怪的问题是由于过度使用时钟。 如果大量最终用户可能使用超频的消费级套件，那么这可能与您的错误有关。

如果你正在运行Linux：

如果你不想重新启动memtest86 +，你可以通过运行memtester来testing内存来查找是否有问题。 对于发现不规则错误以及非确定性错误，它确实做得很好。 它有几个用于捕捉内存边界的testing，并产生详细的故障定位报告，testing运行以及在计算机中查找故障所用的时间。 不需要重新启动，您可以在运行的Linux系统上运行它。

我没有find应用程序的任何链接，但这里是debian软件包的信息 ：

你有没有select在你的系统中使用“镜像内存” – 这将告诉你，如果你有内存问题 – 有这样的地方，有更less的机会，任何错误是由于物理内存的问题。