为什么要使用ECC？杰夫·阿特伍德（Jeff Atwood），也许是最受读者欢迎的编程博客作者，其帖子中提出了反对使用ECC内存的理由。我的读物是他的主要观点是：
如果ECC实际上很重要，它将在所有地方使用，而不仅仅是服务器。支付像这样的可选东西是“非常麻烦的”
如果您只是因为Google曾经做过这些事情而做这些事情，则可以做以下事情：
即使在Google进行的实验被认为是失败的，但今天仍在撰写文章，说明这是一个好主意。事实证明，即使Google的实验也不一定总是成功。实际上，他们倾向于“登峰造极”，这意味着与大多数公司相比，他们拥有更多失败的实验。海事组织，这对他们来说是一个巨大的竞争优势。您无需盲目地复制他们失败的实验，就可以使该优势变得更大。
某些人可能会看到这些早期的Google服务器，发现有业余的火灾隐患。不是我。我对廉价的商品硬件将如何塑造当今的互联网有先见之明。
最后一部分是正确的。但是第一部分也有一定道理。当Google开始设计自己的开发板时，一代人遇到了长生1问题，导致非零次数的火灾。
顺便说一句，如果您单击Jeff的帖子并查看报价所引用的照片，您将看到这些板具有很大的弹性。这引起了问题，并在下一代中得到解决。您还可以观察到布线非常混乱，这也导致了问题，并且在下一代系统中也得到了修复。还有其他问题，但我将留给读者练习。
一代Google服务器具有令人难以置信的锋利边缘，因此享有“剃须刀和仇恨”制成的美誉。
从与许多大型高科技公司的人们交谈时，似乎他们中的大多数人都遇到了气候控制问题，从而导致其数据中心出现云或雾。您可能会将此称为Google的巧妙计划，以重现西雅图的天气，以便他们可以挖走MS员工。或者，这可能是创建文字云计算的计划。或者可能不是。
请注意，这些都是Google尝试然后更改的所有内容。在每个成功的工程组织中，都会犯错误然后加以纠正。如果您打算从事货物崇拜的工程实践，那么至少应该从事货物崇拜的当前工程实践，而不是在1999年完成的工作。
Google在1999年使用不带ECC的服务器时，发现了许多最终归因于内存损坏的症状，包括一个搜索索引，该索引有效地将随机结果返回给查询。此处的实际故障模式具有指导意义。我经常听到，可以忽略这些计算机上的ECC，因为在每个结果中都有错误是可以的。但是，即使您可以容忍偶尔的错误，忽略错误也意味着您将自己暴露在全面的腐败中，除非您进行了非常仔细的分析以确保单个错误只能污染单个结果。在对文件系统进行的研究中，反复表明，尽管做出了勇敢的尝试来创建对单个错误具有鲁棒性的系统，但这样做非常困难，并且基本上每个经过严格测试的文件系统都会因单个错误而导致严重故障（如果对此感到好奇，请参阅威斯康星州Andrea和Remzi研究小组的输出）。我不是在这里敲文件系统开发人员。他们在这种分析方面比99.9％的程序员更好。仅仅是这个问题已经被反复证明足够困难，以至于人们无法有效地推理出这个问题，而用于这种分析的自动化工具仍然离按钮过程还很远。在他们关于仓库规模计算的书中，Google讨论了纠错和检测，当显然您应该使用硬件纠错2时，ECC被视为他们的灌篮案例。
Google拥有出色的基础架构。从我听说过的其他大型科技公司的基础设施来看，Google的声音听起来是世界上最好的。但这并不意味着您应该复制他们所做的所有事情。即使您查看了他们的好主意，对于大多数公司而言，也没有必要复制它们。他们创建了Linux工作窃取调度程序的替代产品，该计划程序同时使用了硬件运行时信息和静态跟踪，从而使他们能够利用Intel服务器处理器中的新硬件，从而使您可以在内核之间动态分区缓存。如果在整个机队中使用，这比在整个历史中用stackexchange在机器上花费的钱轻松地为Google节省了一周更多的钱。这是否意味着您应该复制Google？不，不是这样，除非您已经掌握了所有未完成的工作，其中包括确保核心基础架构使用高度优化的C ++（而不是Java或（上帝禁止）Ruby）编写的东西。事实是，对于绝大多数公司而言，用一种会造成20倍性能损失的语言编写文字是一个完全合理的决定。
针对ECC的案例引用了有关DRAM错误的研究的这一部分（粗体为Jeff's）：
我们的研究有几个主要发现。首先，我们发现大约70％的DRAM故障是重复发生的（例如永久性）故障，而只有30％是瞬态故障。其次，我们发现大型多位故障（例如，影响整个行，列或存储体的故障）占所有DRAM故障的40％以上。第三，我们发现几乎5％的DRAM故障会影响板级电路，例如数据（DQ）或选通（DQS）线。最后，我们发现Chipkill功能将DRAM故障导致的系统故障率降低了36倍。
这有点讽刺，因为这句话听起来不像是反对ECC的论点。听起来像是针对Chipkill（一种特殊的ECC）的争论。抛开这些，Jeff的帖子指出硬错误是软错误的两倍，然后提到它们在获得错误时在计算机上运行memtest。首先，2：1的比例并不大，您可以忽略软错误。其次，该帖子暗示Jeff认为硬错误基本上是不可变的，并且在一段时间后不会浮出水面。那是不对的。您可以将电子设备视为磨损，就像机械设备的磨损一样。机制不同，但效果相似。实际上，如果将芯片的可靠性分析与其他类型的可靠性分析进行比较，您会发现它们经常使用相同的分布族来建模故障。第三，Jeff的推理路线意味着ECC无法帮助检测或纠正硬错误，这些错误不仅不正确，而且与报价直接矛盾。
因此，您打算多久在计算机上运行一次memtest来捕获这些硬错误，以及您愿意忍受多少数据损坏？ ECC的主要用途之一不是纠正错误，而是发信号通知错误，以便可以在出现静默损坏之前更换硬件。没有人会同意每天关闭一台机器上的所有程序来运行memtest（这比买ECC内存要贵得多），即使您可以说服人们这样做，它也不会捕获到那么多错误。 ECC将。
当我在一家拥有约1000台计算机的公司工作时，我们注意到我们遇到了奇怪的一致性检查故障，也许在半年后，我们意识到故障发生在某些计算机上的可能性要大于其他计算机。故障很少发生，平均一周可能会发生几次，因此花费大量时间来累积数据，并且需要更多时间让人们意识到正在发生的事情。在不知道原因的情况下，分析日志以找出错误是由单个位翻转（很有可能）引起的也是很重要的。我们很幸运，作为所使用过程的副作用，校验和是在不同的计算机上，在不同的时间，在单独的过程中计算出来的，因此，错误不会破坏结果并将此破坏传播到计算机中。校验和。如果您只是尝试使用内存中的校验和来保护自己，那么很有可能会对已损坏的数据执行校验和运算，并计算出不良数据的有效校验和，除非您在进行一些真正花哨的计算时它们自己的校验和（如果您对错误纠正如此认真，那么无论如何都可能使用ECC）。无论如何，在完成分析之后，我们发现memtest无法检测到任何问题，但是在故障机器上更换RAM会导致错误率降低一到两个数量级。大多数服务没有我们拥有的这种校验和。这些服务将简单地以静默方式将损坏的数据写入持久性存储，并且直到客户抱怨后才注意到问题。
帖子中的数据不足以支持此断言。请注意，由于RAM使用量一直在增加并且以快速指数速率持续增加，因此RAM故障必须以更大的指数速率减少，才能真正减少数据损坏的可能性。此外，随着芯片的不断缩小，功能变得更小，使得“ 2”中讨论的磨损问题更加普遍。例如，在20nm的情况下，一个DRAM电容器可能容纳约50个电子，而下一代DRAM的数字将变得越来越小，并且事情还在继续缩小。
Atwood引用的2012年研究在以下图表上显示了随机选择的十个故障节点（6％的节点至少有一个故障）上的校正错误（所有错误的子集）：
对于正在发生故障的典型节点，我们正在讨论10到10k个错误，这是一篇帖子中的引人入胜的研究，该文章认为您不需要ECC。请注意，这里的节点仅具有16GB的RAM，这比现代服务器通常的内存少一个数量级，并且这是在较旧的过程节点上进行的，该节点比我们现在更不容易受到噪声的影响。对于习惯于处理可靠性问题并且只想了解FIT率的任何人，研究发现FIT率在每Mbit 0.057到0.071个故障之间（与Atwood的说法相反，这不是一个令人震惊的低数字）。如果您采用最乐观的FIT速率.057，并为没有太多RAM的服务器（此处使用的是128GB，因为如今我看到的服务器通常具有128GB至1.5TB的RAM）进行计算。每个服务器每年获得的期望值为.057 * 1000 * 1000 * 8760/1000000000 = 0.5个故障。请注意，这是针对错误而非错误。从上图可以看出，一个故障每月很容易导致数百或数千个错误。要注意的另一件事是，有多个节点在研究开始时没有错误，但后来又出现了错误。
数十年前，Sun / Oracle曾广为人知。晶体管和DRAM电容器变得越来越小，与现在一样，存储器使用和高速缓存也越来越多。在拥有较小的晶体管以抵抗瞬态不稳定性以及更难以制造以及拥有更多的片上高速缓存之间，绝大多数服务器供应商决定在其高速缓存中添加ECC。 Sun决定省下几美元，而跳过ECC。直接的结果是许多Sun客户报告了零星的数据损坏。 Sun花了多年的时间才开发出具有ECC缓存的新体系结构，并且Sun使客户签署了NDA以获取替换芯片。当然，没有办法永远掩盖这种情况，当它浮出水面时，Sun生产可靠服务器的声誉便受到了永久性的打击，就像他们试图通过在其条款中引入条款来掩盖性能低下的结果一样。不允许进行基准测试的服务。
这里要注意的另一件事是，当您为ECC付费时，您不仅在为ECC付费，而且还在为质量更高的零件（CPU，主板）付费。您可以通过磁盘故障率轻松地看到这一点，而且我已经看到很多人在自己的私有数据集中看到了这一点。在公共数据方面，我相信几年前Andrea和Remzi的小组有一份SIGMETRICS论文，该论文显示SATA驱动器发生磁盘读取故障的可能性比SCSI驱动器高4倍，而无声数据损坏的可能性则高10倍。即使对于同一制造商的驱动器，这种关系也成立。没有特别的理由认为SCSI接口应该比SATA接口更可靠，但这与接口无关。这是关于购买高可靠性服务器部件而不是消费者部件。也许您并不是特别在意磁盘的可靠性，因为您可以对所有内容进行校验和并可以轻松检测到磁盘损坏，但是有些类型的损坏很难检测到。
4.如果ECC实际上很重要，它将在所有地方使用，而不仅仅是服务器。
稍微改写一下，该论点是“如果此功能对于服务器实际上很重要，它将在非服务器中使用”。您可以就大量服务器硬件功能提出此论点。这实际上是大型云供应商面临的最令人讨厌的问题之一-硬件供应商能够提高具有服务器功能的部件的价格，因为这些功能在服务器应用程序中比在桌面应用程序中更有价值。大多数家庭用户并不介意，这为硬件供应商提供了一种机制，使他们可以从购买服务器的人们中提取更多的钱，同时仍为消费者提供便宜的零件。
云供应商通常具有足够的谈判能力来按成本购买零件，但这仅在有多个可行供应商的地方有效。在没有任何竞争对手的情况下，少数几个领域中的一些领域包括CPU和GPU。 CPU供应商已经进行了许多尝试进入服务器市场的尝试，但是到目前为止，每一次尝试都存在致命的缺陷，从早期就可以明显看出这种尝试注定要失败（并且这些通常是5年的项目，因此要花很多时间在一个注定的项目上）。高通公司的努力得到了很多炒作，但是当我与高通人员交谈时，我知道他们都告诉我当前的芯片基本上是用于实践的，因为高通公司需要从他们所有的人那里学习如何构建服务器芯片。从IBM挖来的，下一代芯片是第一个有竞争力的芯片。我对高通以及ARM努力构建好的服务器部件寄予厚望，但这些努力仍遥遥领先。
就每TCO美元的性能而言，当前的ARM（和POWER）选件（不包括Apple令人印象深刻的ARM芯片的假设变体）几乎不适合大多数服务器工作负载，这是一个切线，所以我将其留给另一篇文章，但关键是英特尔有市场力量让人们为服务器功能支付额外费用，而他们这样做。此外，对于服务器来说，某些功能确实比对具有几GB RAM和几瓦功率预算的移动设备更为重要，而这些移动设备预计会随机崩溃并会定期重新启动。
您应该购买ECC RAM吗？那要看。对于服务器，考虑到成本，这可能是一个不错的选择，尽管实际上很难进行成本/收益分析，因为实际上很难弄清静默数据损坏的成本，或者有可能烧掉半年的数据成本。开发人员在追踪间歇性故障时仅发现这是由使用非ECC内存引起的。
对于正常的台式机使用，我使用pro-ECC，但是如果您没有设置常规备份，则进行备份可能比ECC具有更好的ROI。但是，如果您有没有ECC的备份，则可以轻松地将损坏的数据写入主存储并将该损坏的数据复制到备份中。
如果您允许任何类型的代码执行，甚至包括沙盒执行，那么诸如rowhammer之类的攻击都可能使用户造成数据损坏，并且在某些情况下允许特权升级。 ECC不能完全缓解攻击，但会增加难度。
至少对我来说，我能想到的一个有趣的例子是神奇的自我修复保险丝。尽管实现方式很多，但您可以将芯片上的保险丝看作是电阻。如果通过它运行一些电流，则应该获得连接。如果流过大量电流，则会加热电阻并最终将其损坏。这通常用于熔断芯片上的功能，或执行诸如设置时钟频率之类的操作，其想法是一旦熔断保险丝，就无法解开保险丝。
曾几何时，有一家半导体制造商在某种特定的工艺世代中匆匆忙忙地制造了一些工艺，并将公差降低得太细了。几个月（或几年）后，保险丝两端之间的连接可能会重新生长，并导致保险丝熔断。如果幸运的话，保险丝将类似于时钟倍频器的高阶位，如果更换，基本上可以使芯片变砖。如果您不走运，它将导致静默数据损坏。
我从那个制造商那里听到了特定过程生成中的问题，这些制造者来自不同公司的多个人，所以这不是孤立的事情。当我说这很有趣的时候，我的意思是当您在酒吧听到这个故事时，这很有趣。经过一年的测试后，您发现某些芯片因保险丝设置不合理而出现故障，并且您必须重新旋转芯片并将发布推迟3个月，这也许不太有趣。顺便说一句，这种保险丝再生长的事情是可以通过ECC缓解的另一类错误的例子。
这不是Google遇到的问题；我之所以仅提及这一点，是因为与我交谈的很多人都对硬件发生故障的方式感到惊讶。
[返回]
如果您不想深入阅读整本书，则大多数相关文章是：
在可以在软件级别容忍大量故障的系统中，对硬件层的最低要求是始终及时检测到故障并将其报告给软件，以允许软件基础结构包含并采取措施。适当的恢复措施。不一定需要硬件透明地纠正所有故障。这并不意味着用于此类系统的硬件应设计为没有纠错功能。只要能够以合理的成本或复杂性提供纠错功能，通常都需要为其提供支持。这意味着，如果硬件纠错的成本过高，则系统可以选择使用仅提供检测功能的价格较低的版本。现代DRAM系统是其中可以以非常低的额外成本提供强大的纠错功能的一个很好的例子。但是，放宽对检测到硬件错误的要求将更加困难，因为这意味着每个软件组件都将负担检查其自身正确执行的需求。在历史的早期，Google必须处理具有甚至缺乏奇偶校验的DRAM的服务器。生成Web搜索索引本质上包括一个非常大的随机/合并排序操作，需要长时间使用多台计算机。在2000年，当一部分经过测试的查询为
......