我有几百台计算机在运行应用程序。在一台计算机上,我看到在一些字符串上错误地设置了两个实例,这些字符串是我从SQLite中提取出来的。如果这是我的开发计算机,我会假设我有一个错误,但肯定有一些安装,我将开始看到罕见的硬件错误。
这当然取决于我做了多少IO,但是当有机会看到这种事情时,是否有任何规则?例如,对于TCP数据包,this paper确定“大约在1600万到100亿个数据包中”将发生静默,未检测到的损坏。
不幸的是,不太可能在相关机器上运行mem / disk checker。
答案 0 :(得分:4)
当我发现奇怪的事情发生时,我的策略是:
在我10年的职业生涯中,99,99%的错误与软件有关。
希望这有帮助。
答案 1 :(得分:2)
会发生误码。考虑使用CRC或其他类型的错误检测/纠正机制来保护您的数据。它发生的几率取决于你拥有什么样的硬件。如果你有ECC的内存,那么它的可能性就会低于你没有的内存,但即便ECC内存也会变坏,也可能无法纠正错误。有几百台计算机我会说奇怪的硬件错误很可能是每天发生的,可能是肯定的。
答案 2 :(得分:1)
"Wikipedia: ECC memory" 说 “最近的DRAM测试给出了大大不同的错误率,超过7个数量级的差异,范围从10 ^ -10到10 ^ -17错误/位·h,大约一位错误,每小时,每GB内存到一位错误,每个世纪,每千兆字节的记忆。[7] [11] [12]“
即使我们使用每千兆每GB一位错误的最乐观估计,如果你有100台计算机的集群,每台计算机有2 GB RAM,这意味着你每年会看到两次误码。 (这只包括RAM位错误。您提到TCP数据包未检测到损坏,您可能还会考虑磁盘驱动器故障,意外电源线拔出,冷却风扇故障等)。 更悲观的估计意味着你会更频繁地看到比特错误 - 正如史蒂夫贝克所说,比特错误是不可避免的。
答案 3 :(得分:0)
有微妙的错误,它可以随时发生,也可以从多个来源发生,甚至是most unlikely。
正如您可以看到在一台计算机上发生的错误,您最好的选择是处理损坏而不是依赖统计信息来告诉您何时可能出现问题。虽然错误可能是由于外部因素造成的,但如果您看到多个错误,那么让机器上运行的memchecker检查其硬件是否有问题是明智的。另一种选择是相信运气,你不会看到完全失败。
答案 4 :(得分:0)
切换机器。在我目前的位置(〜7年),我曾经看过一次由硬件内存错误引起的蓝屏。如果你在同一台机器上看到两次误码失败,很有可能你找到了罪魁祸首。在同一段时间里,我看到了几十个磁盘控制器故障/磁盘故障/注册表损坏蓝屏。所以它们很少见,但它们确实发生了。
在网络方面,我们遇到过一个案例,其中一个3d派对供应商的WAN压缩设备正在将我们的应用程序TCP数据包压缩在一起,不正确,然后在其上放置一个好的CRC。这至少可以说是造成严重破坏。