33

大多数可用的桌面(廉价)x86 平台现在仍然没有 ECC 内存支持(错误检查和纠正)。但是内存位翻转错误率仍在增长(不是最好的 SO 线程大规模 CERN 2007 研究“数据完整性”:“他们的内存模块的位错误率为 10 -12 ...观察到的错误率为 4 个订单数量级低于预期”;2009 年 Google 的“野外 DRAM 错误:大规模现场研究”)。对于当前具有数据密集型负载(8 GB/s 读取)的硬件,这意味着可能每分钟发生一次位翻转(来自 CERN07 的 10 -12个供应商 BER)或两天一次(10 -16BER 来自 CERN07)。Google09 表示,每 Mbit 最多可以有 25000-75000 位 FIT(每十亿小时的时间故障),这相当于 8GB RAM 每小时 1-5 位错误(“平均可纠正错误率为 2000–每年每 GB 6000 ")。

所以,我想知道,是否可以在系统范围内添加某种软件错误检测(检查用户和内核内存)。例如,为 Linux 内核和/或系统编译器创建一个补丁,为每个内存页面添加一些校验和,并尝试通过定期重新计算校验和来检测静默内存损坏(位翻转)?

例如,我们能否看到所有对内存的写入(来自用户和内核空间),以区分预期的内存更改和内存中的位翻转?或者我们可以以某种方式使用一些助手来检测所有代码吗?

我知道任何类型的软件内存 ECC 可能会消耗大量性能并且不会捕获所有错误,但我认为在它们将在以后的计算中重用或存储之前尽早检测到至少一些内存位翻转可能很有用到硬盘。

我也明白更好的数据保护方法是切换到 ECC 硬件,但大多数 PC 仍然是非 ECC。

4

2 回答 2

5

问题是,与“软件 ECC 对策”相比,ECC 非常便宜。您可以轻松检测他们是否有 ECC 模块,并在没有时抱怨(或打印警告)。

http://www.cyberciti.biz/faq/ecc-memory-modules/

例如,我们能否看到所有对内存的写入(来自用户和内核空间),以区分预期的内存更改和内存中的位翻转?或者我们可以以某种方式使用一些助手来检测所有代码吗?

呃,你永远不会“看到”总线上的位翻转。它们实际上是由粒子撞击 RAM 引起的,稍微翻转一下。直到很久以后,您才能注意到您读出的内容与您写入的内容不同。要仅通过总线检测到这一点,您需要所有RAM 的副本(即创建真实 RAM 中内容的影子副本,所以您可以验证每次读取都返回写入该位置的内容。)

尝试通过定期重新计算校验和来检测静默内存损坏(位翻转)?

Redis 的家伙有一篇关于测试 RAM 是否存在问题的算法的文章。http://antirez.com/news/43 但这确实是在寻找 RAM 错误,而不是随机位翻转。

如果“重新计算校验和”仅在您不写入内存时有效。这可能“足够好”,但您需要弄清楚哪些页面没有被写入。

为了捕获 100% 的错误,每次写入都必须先计算该内存块的校验和,然后将其与记录的校验和进行比较(以确保该块在 RAM 中没有降级)。只有这样才能安全地进行写入然后更新校验和。正如你可以想象的那样,它的性能将是可怕的(至少慢 100 倍)性能。

我知道任何类型的软件内存 ECC 都可能会消耗大量性能并且不会捕获所有错误,但我认为尽早检测至少一些内存位翻转是有用的,然后它们将在以后的计算中重用或存储到硬盘。

好吧,有一种简单的方法可以检测 100% 的错误,但代价是 50% 的性能:只需一次在 2 个盒子上运行计算(或者在两个不同时间在一个盒子上运行计算,如果你是偏执狂。)如果结果不同,你检测到一个错误。

也可以看看:

https://www.linuxquestions.org/questions/linux-hardware-18/how-to-detect-ecc-memory-errors-under-linux-886011/

于 2014-06-18T15:55:34.100 回答
1

问题的答案是肯定的,评论中发布的软件SoftECC就是证明!

请注意,SoftECC 是内核级解决方案。如果使用用户级应用程序,这将是第三阶段的冗余,这似乎没有必要。

于 2014-06-05T01:36:41.943 回答