Answers:
在服务器级别为36的服务器中,我发现ECC电路每3个月检测一次可纠正的故障。
如果您怀疑内存故障,则应该运行memtest86
,这是当今几乎所有流行的Linux发行版中都附带的。
从Robin Harris的DRAM错误率得出:DIMM街上的噩梦:
一项针对两年半的数千台Google服务器上的DRAM的研究历时两年半,发现DIMM错误率比预期高出数百至数千倍-平均每个DIMM每年可纠正3,751个错误。
哈里斯(Harris)引用了对Google的服务器群进行了2.5年的研究。请注意,服务器通常使用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 GB的内存中至少发生一位错误的可能性超过95%。
当我们未能确定坠机原因时,下一次同事说“宇宙射线”时,我不会笑。
您可以使用memtest86 +引导计算机,并在一夜之间进行检查。那就是我发现问题的方式。
是的,我已经看到记忆棒变坏了,它们只会在一种特定的记忆写模式下失败。计算机的BIOS未检测到问题,但memtest86在夜间运行时发现了该问题。
我已经看到过去十年来使用的大约五十台计算机中有两根RAM坏了。它发生,但不经常发生。
在过去的十年左右的时间里,我已经看到少数几个内存模块在运行中的服务器中完全失败,而在新交付的硬件上进行Memtest86刻录时,出现的故障数量略多。这些是服务器系统,几乎所有服务器系统都将具有一种或另一种类型的ECC内存,因此,我希望具有非纠错RAM的客户端系统上的问题更加频繁。我没有大量的示例可用于工作,我们拥有几十个服务器,就调试客户系统而言,我要说的是我已经在100个左右的水平上工作了。 d实际上要注意RAM。
在客户端方面,我在企业级方面有更多经验-我是管理50k最终用户PC的小组的高级工程师几年,我们从来没有将RAM的硬件或软件故障视为一个重大问题,当然这不是影响到任何可测量系统百分比的东西。这并不是说它没有发生,只是如果这个问题影响到超过1%的商务台式机和笔记本电脑,我会感到非常惊讶。一些特定的型号将展示出与构建质量控制有关的非常高的故障率,第一批IBM Thinkpad T30的第二个DIMM插槽出现问题,导致我们不得不一次维修/更换数千台机器。
Microsoft的Larry Osterman于2005年撰写的这篇博客文章可能会为其中的某些问题提供可能的解释-他对Windows错误报告中相当大的数据集中报告的一些奇怪错误的分析表明,其中许多奇怪的问题是由过度计时。如果您的大量最终用户可能正在使用超频的消费者级别套件,则这可能与您的错误有关。
您是否可以选择在系统中使用“镜像内存”-会告诉您是否存在内存问题-有了这种选择,发生任何错误是由于物理内存问题导致的可能性大大降低。
如果您正在运行Linux:
如果您不想重新启动进入memtest86 +,则可以通过运行memtester来测试内存以查找其是否有故障来获得一些结果。它对于发现不规则故障以及其中包含非确定性故障都非常有现实意义。它具有用于捕获内存边界的多个测试,并生成详细的故障报告,所定位的故障,测试运行以及在计算机中查找故障所花费的时间。无需重启,您可以在运行的Linux系统上运行它。
我没有找到该应用程序的任何链接,但这是debian软件包的信息: