アプリを実行しているコンピューターが数百台あります。1台のコンピューターで、SQLiteから引き出した一部の文字列に1ビットの2つのインスタンスが正しく設定されていないのを確認しました。これが私の開発用コンピューターである場合、どこかにバグがあると思いますが、確かにいくつかのインストールがあり、その時点でまれなハードウェアベースのエラーが発生し始めます。
これは確かに私が行うIOの量に依存しますが、この種のものを見る可能性が十分にある場合の経験則はありますか？たとえば、TCPパケットの場合、このペーパーでは、「1600万から100億パケットの約1つ」でサイレントで検出されない破損が発生すると判断しました。
残念ながら、問題のマシンでmem/diskチェッカーを実行することは起こりそうにありません。
奇妙なことが起こっていることに気付いたときの私の戦略は次のとおりです。
私の10年間のキャリアでは、バグの99,99％がソフトウェアに関連していました。
お役に立てれば。
ビットエラーが発生します。CRCまたはその他の種類のエラー検出/訂正メカニズムを使用してデータを保護することを検討してください。それが発生する確率は、使用しているハードウェアの種類によって異なります。ECCを備えたメモリがある場合、たとえばそうでない場合よりも可能性は低くなりますが、ECCメモリでさえ不良になり、エラーの修正に失敗する可能性があります。数百台のコンピューターでは、奇妙なハードウェアエラーが毎日発生する可能性が非常に高く、おそらく確実であると言えます。
「ウィキペディア: ECC メモリ」 には、「最近の DRAM テストでは、10^−10 から 10^−17 エラー/ビット・時間の範囲で、7 桁を超えるさまざまなエラー率があり、1 時間あたり、1 時間あたり、約 1 ビット エラーです。ギガバイトのメモリから 1 ビット エラーまで、世紀ごと、メモリのギガバイトごとに。[7][11][12]"
世紀ごとにギガバイトあたり 1 ビット エラーという最も楽観的な見積もりを使用したとしても、それぞれ 2 GB の RAM を備えた 100 台のコンピューターのクラスターがある場合、年に 2 回ビット エラーが発生することを意味します。（これにはRAMビットエラーのみが含まれます。TCPパケットの検出されない破損について言及しましたが、ディスクドライブの障害、偶発的な電源コードの抜き差し、冷却ファンの障害なども考慮する場合があります）。より悲観的な見積もりは、ビット エラーがはるかに頻繁に発生することを意味します。Steve Baker が言ったように、ビット エラーは避けられません。
微妙なエラーがあると、いつでも発生する可能性があり、いくつかのソースから発生する可能性があります。
1台のマシンでエラーが発生していることがわかるので、統計に頼って問題が発生したときに通知するのではなく、損傷を処理するのが最善の方法です。エラーは外部要因が原因である可能性がありますが、複数のエラーが発生した場合は、そのmemcheckerをマシンで実行して、ハードウェアに障害がないことを確認することをお勧めします。別の方法は、完全な失敗が見られないという幸運を信頼することです。
そのマシンを切り替えます。私の現在のポジション (~7 年) で、ハードウェア メモリ エラーが原因でブルースクリーンが表示されるのを 1 回見たことがあります。同じマシンでビット エラー エラーが 2 回発生する場合は、原因が見つかった可能性があります。同じ期間に、ディスク コントローラの障害、ディスクの障害、レジストリの破損によるブルースクリーンが何十回も表示されました。したがって、それらはまれですが、発生します。
ネットワーク側では、サード パーティ ベンダーの WAN 圧縮デバイスがアプリの TCP パケットを誤ってまとめて圧縮し、適切な CRC を適用するケースがありました。それは控えめに言っても大混乱を引き起こしました。