サーバークラスのハードウェアの場合、RAM=
多くのサーバークラスのシステムには ECC RAM が装備されているという事実を考えると、展開前に burn-in メモリーDIMMを使用する必要があるのでしょうか？
allサーバーRAMが長いバーンイン/ストレステスティングプロセスを介して配置されている環境に遭遇しました。これによりシステムの展開が遅れました時々、ハードウェアのリードタイムに影響を与えます。
サーバーハードウェアは主に Supermicro であるため、RAMはさまざまなベンダーから提供されています。 Dell Poweredge のような製造元から直接提供されたものではありません。または HP ProLiant 。
これは便利な練習ですか？私の過去の経験では、単にベンダーを使用しましたRAMそのままの状態です。 [〜＃〜] post [〜＃〜] メモリーテストがDOAをキャッチするべきではありませんメモリ？通常、ECCしきい値が保証配置のトリガーであったため、DIMMが実際に故障するずっと前にECCエラーに応答しました。
- yourRAMを焼き付けますか？
- その場合、どのような方法でテストを実行しますか？
- 展開の前に問題を特定しましたか？
- バーンインプロセスにより、そのステップを実行しない場合と比べて、プラットフォームの安定性が向上しましたか？
- 既存の実行中のサーバーにaddingRAM
私は ドキュメント をキングストンがサーバーメモリでどのように使用するかを詳しく説明しているのを見つけました。このプロセスは、通常、ほとんどの既知の製造業者と同じであると思います。メモリチップとすべての半導体デバイスは、バスタブカーブと呼ばれる特定の信頼性/故障パターンに従います。
時間は横軸に表され、工場出荷から始まり、次の3つの異なる期間が続きます。
初期の生活障害：ほとんどの故障は、初期の使用期間中に発生します。ただし、時間の経過とともに、障害の数は急速に減少します。黄色で示されている初期生活障害期間は約3か月です。
耐用年数：この期間中、障害は非常にまれです。耐用年数は青色で表示され、20年以上と推定されます。
寿命末期の故障：最終的には、半導体製品は摩耗して故障します。サポート終了期間は緑色で表示されます
キングストンは、最初の3か月で故障率が高くなると述べたため（この3か月後は、約15〜20年後のEOLになるまで、ユニットは良好と見なされます）。彼らは、KT2400と呼ばれるユニットを使用してテストを設計しました。このユニットは、serverメモリモジュールを100℃で24時間高電圧で残酷にテストします。すべてのDRAMチップの継続的に行使されます。この高レベルのストレステストには、モジュールを少なくとも3か月間エージングする効果があります（ほとんどのモジュールで障害が発生する重要な期間の前に注記したとおり）。
結果は次のとおりです。
2004年3月、キングストンは6か月のトライアルを開始し、サーバーメモリの100％がKT2400でテストされました。結果を注意深く監視して、障害の変化を測定しました。 2004年9月、すべてのテストデータが収集および分析された結果、故障は90％減少したことがわかりました。これらの結果は期待を上回り、すでにクラスのトップにあった製品ラインの大幅な改善を表しています。
では、なぜメモリへの書き込みがサーバーのメモリに役立たないのでしょうか。単に、それはすでにあなたの製造業者によって行われているからです！
番号。
ハードウェアの焼き付けの目的は、コンポーネントの障害を触媒するポイントまでハードウェアにストレスをかけることです。
機械的なハードドライブでこれを行うと、いくつかの結果が得られますが、RAMに対してはあまり効果がありません。コンポーネントの性質上、RAM（最大帯域幅でも数時間または数日間）に読み書きするよりも、環境要因と年齢が障害の原因である可能性がはるかに高い）になるだろう。
RAM=は、実際に使い始めたときにはんだが溶けないほどの高品質であると仮定すると、バーンインプロセスは欠陥の発見に役立ちません。
私たちはブレードを購入し、通常は一度にかなり大きなブロックを購入します。そのため、ネットワークポートの準備ができて安全になる前に、ブレードを取り込んで数日かけてインストールします。そのため、memtestを24時間程度使用するためにその時間を使用します。週末になる場合はさらに長くなることがあります。完了したら、基本的なESXiをスプレーダウンし、ネットワークが稼働したらIPでホストプロファイルを適用する準備が整います。ええ、私たちはそれをテストします。必要以上に機会から外れますが、それは今までにいくつかのDOA DIMMを捕まえました。私はそれのためです。
まあ、それはあなたのプロセスが何であるかに正確に依存すると思います。 MemTest86をシステム（サーバーなど）に配置する前に、常にメモリ上で実行します。システムを稼働させた後は、メモリの不良が原因のトラブルシューティングは困難です。
実際に記憶を「ストレステスト」することに関しては;あなたがオーバークロックの目的でテストしているのでない限り、これがなぜ役立つのか私はまだ知りません。
私はしませんが、そうする人を見てきました。私は彼らがそれから何かを得るのを見たことはありませんが、それはおそらく二日酔いや迷信かもしれないと思います。
個人的には、ECCエラー率が私にとってより有用であるという点で私はあなたのようです-RAMはDOAではないと仮定しますが、とにかくそれを知っています。
通常、システムの実行中にビットエラーを検出する信頼できる方法がないため、ECC以外のRAMの場合、memtest86 +で30分間実行すると便利です。
ブルースクリーンは信頼できる方法とは見なされていません...
そして、わずかに不安定なRAMは、システムがメモリ全体の負荷を確認した後で、そのRAMのデータがコードである場合にのみ、すぐに表示されないことがよくありますそれは慣れてからクラッシュしました。データの破損は長期間気付かれない可能性があります。
ECC ramの場合、メモリコントローラー自体が行うことは何もしないため、意味がありません。時間の無駄です。
私の経験では、焼き付きを主張する人は通常、いつもこのようにしていて、本当に真実であると考えずに習慣からそれを続けている老人です。
または、彼らはそれらの古い男によって書かれた所定の手順に従う若い男です。
場合によります。
50 000個の新しいRAMを展開していて、この特定のハードウェアの稼働率が1日未満で0.01％であることがわかっている場合、統計的に言えば、初日に故障するRAMがいくつかあります。焼き付きはそれをキャッチするためのものです。この規模のデプロイメントでは、例外的な状況ではなく、失敗が予想されます。
ただし、数百のアイテムのみを展開している場合、失敗したパーツを取得するのは非常に不運でなければならないため、統計はおそらくあなたの側にあります。
1つのサーバーでは、状況に応じて、時間の浪費になる可能性があります。
しかし、一度に2000台のサーバーをインストールし、有効な「ストレステスト」を行わない場合は、動作が悪いサーバーを1つ見つけることは間違いありません。そしてそれはRAMだけでなく、ネットワーク、CPU、ハードドライブなどのためでもあります。1つのDIMMを交換するときも、それは良いことです。なので、ストレステストを起動すると、修正されているかどうかがわかります。
大規模クラスターでの私の経験から、HPLはDIMMエラーがあるかどうかを判断するのに適したツールです。また、モノノードHPLで十分ですが、より大きなHPLも役立ちます。システムが期待どおりに動作し、Linuxでログに記録されるMCEエラーをスローしない場合は、問題ありません。