Apakah perlu membakar RAM untuk perangkat keras kelas server?

31

Mempertimbangkan fakta bahwa banyak sistem kelas server dilengkapi dengan RAM ECC , apakah perlu atau berguna untuk membakar DIMM memori sebelum digunakan?

Saya mengalami lingkungan di mana semua RAM server ditempatkan melalui proses burn-in / stress-tesing yang panjang. Hal ini kadang-kadang memperlambat penerapan sistem dan memengaruhi waktu tunggu perangkat keras.

Perangkat keras server utamanya adalah Supermicro , sehingga RAM bersumber dari berbagai vendor; tidak langsung dari pabrikan seperti Dell Poweredge atau HP ProLiant .

Apakah ini latihan yang bermanfaat? Dalam pengalaman masa lalu saya, saya hanya menggunakan RAM vendor di luar kotak. Bukankah tes memori POST menangkap memori DOA? Saya telah merespons kesalahan ECC jauh sebelum DIMM benar-benar gagal, karena ambang ECC biasanya menjadi pemicu penempatan garansi.

  • Apakah Anda membakar RAM Anda ?
  • Jika demikian, metode apa yang Anda gunakan untuk melakukan tes?
  • Apakah sudah mengidentifikasi masalah sebelum penempatan?
  • Apakah proses burn-in menghasilkan stabilitas platform tambahan versus tidak melakukan langkah itu?
  • Apa yang Anda lakukan saat menambahkan RAM ke server yang sedang berjalan?
putih
sumber

Jawaban:

25

Saya menemukan dokumen oleh Kingston yang merinci cara kerjanya dengan Memori Server, saya percaya bahwa proses ini, biasanya, akan sama untuk sebagian besar produsen yang dikenal. Chip memori, serta semua perangkat semikonduktor, mengikuti pola keandalan / kegagalan tertentu yang dikenal sebagai Bathtub Curve:

masukkan deskripsi gambar di sini

Waktu direpresentasikan pada sumbu horizontal, dimulai dengan pengiriman pabrik dan berlanjut melalui tiga periode waktu yang berbeda:

  • Kegagalan Kehidupan Awal: Sebagian besar kegagalan terjadi selama periode penggunaan awal. Namun, seiring berjalannya waktu, jumlah kegagalan berkurang dengan cepat. Periode Kegagalan Kehidupan Awal, ditunjukkan dengan warna kuning, adalah sekitar 3 bulan.

  • Kehidupan yang Berguna: Selama periode ini, kegagalan sangat jarang terjadi. Periode masa manfaat ditunjukkan dengan warna biru dan diperkirakan lebih dari 20 tahun.

  • Kegagalan Akhir Kehidupan: Akhirnya, produk semikonduktor aus dan gagal. Periode Akhir Kehidupan ditunjukkan dengan warna hijau

Sekarang karena Kingston mencatat bahwa tingkat kegagalan yang tinggi akan terjadi pada tiga bulan pertama (setelah tiga bulan unit ini dianggap baik sampai EOL sekitar 15 - 20 tahun kemudian). Mereka merancang tes menggunakan unit yang disebut KT2400 yang secara brutal menguji modul memori server selama 24 jam pada 100 derajat celcius pada tegangan tinggi, di mana semua sel dari setiap chip DRAM terus dilakukan; pengujian stres tingkat tinggi ini memiliki efek menua modul setidaknya tiga bulan (seperti dicatat sebelum periode kritis di mana sebagian besar modul menunjukkan kegagalan).

Hasilnya adalah:

Pada Maret 2004, Kingston memulai uji coba enam bulan di mana 100 persen dari memori servernya diuji di KT2400. Hasil dimonitor untuk mengukur perubahan dalam kegagalan. Pada bulan September 2004, setelah semua data uji dikumpulkan dan dianalisis, hasilnya menunjukkan bahwa kegagalan berkurang hingga 90 persen. Hasil ini melebihi harapan dan mewakili peningkatan yang signifikan untuk lini produk yang sudah di atas kelasnya.

Jadi mengapa membakar memori tidak berguna untuk memori server? Sederhananya, karena itu sudah dilakukan oleh pabrikan Anda!

Lucas Kauffman
sumber
10
Pembuat chip, dan mungkin bahkan vendor server dapat menguji beberapa chip. Tetapi komponen mst hanya diuji sampel akhir-akhir ini untuk mengurangi biaya. Sekalipun chip Anda atau seluruh DIMM pernah diuji, itu tidak memberi tahu Anda jika kontak atau PCB mengalami perubahan atau kekacauan selama perakitan atau pengiriman. Kami telah menemukan masalah burn-in menemukan MemTEst86 dengan memori dari dua server yang berbeda, out-of-the-box dari dua vendor server "tier 1" yang berbeda. Jika mereka berhasil berproduksi, ECC mungkin telah menyelamatkan kami, tetapi korupsi basis data diam-diam juga bisa menjadi akibatnya.
rmalayter
7
Kurva bathtub ini bukan hanya untuk semikonduktor. Sebagian besar komponen dibangun dengan tingkat kontrol kualitas apa pun mengikutinya: hard drive, SSD, catu daya (terutama karena kapasitor), kipas, dll.
voretaq7
6
Ini adalah salah satu alasan saya tidak pernah membeli perpanjangan garansi untuk elektronik. Perangkat (atau komponen) akan gagal dalam beberapa bulan pertama atau akan berlangsung seumur hidup. Ini juga menunjukkan mengapa sangat penting untuk menyingkirkan apel yang buruk lebih awal sehingga Anda bisa mendapatkan kelancaran berlayar sesegera mungkin.
Atari911
@ rmalayter Jadi Anda tetap menyarankan untuk membakar RAM?
ewwhite
2
@white Ya, saya akan menguji. Hanya perlu beberapa jam untuk mem-boot memtest86 dan membiarkannya memeriksa 384 GB RAM. Kami membakar semua subsistem penyimpanan juga menggunakan IOmeter untuk alasan yang sama. Apakah beberapa pengontrol RAID atau drive mati pada kita selama burn-in selama beberapa tahun terakhir, meskipun mereka awalnya bekerja dengan baik selama instalasi OS. Kadang-kadang itu adalah hal firmware yang buruk, kadang-kadang RAM cache salah pada controller RAID, kadang-kadang itu "siapa tahu - RMA itu!"
rmalayter
30

Tidak.

Tujuan pembakaran dalam perangkat keras adalah untuk menekankannya sampai mengkatalisasi kegagalan pada suatu komponen.

Melakukan ini dengan hard drive mekanis akan mendapatkan beberapa hasil, tetapi tidak akan banyak membantu RAM. Sifat komponen adalah sedemikian rupa sehingga faktor lingkungan dan usia jauh lebih mungkin menjadi penyebab kegagalan daripada membaca dan menulis ke RAM (bahkan pada bandwidth maksimum selama beberapa jam atau hari).

Dengan asumsi RAM Anda cukup berkualitas sehingga solder tidak akan meleleh saat pertama kali Anda benar-benar menggunakannya, proses pembakaran tidak akan membantu Anda menemukan cacat.

Shane Madden
sumber
15

Kami membeli pisau dan kami biasanya membeli dalam jumlah yang cukup besar pada satu waktu, karena itu kami mendapatkannya dan memasangnya selama HARI sebelum port jaringan kami siap / aman. Jadi kami menggunakan waktu itu untuk menggunakan memtest selama sekitar 24 jam, kadang-kadang lebih lama jika melewati akhir pekan - setelah selesai, kami menyemprot ESXi dasar dan IP siap untuk profil hostnya untuk diterapkan setelah jaringan naik. Jadi ya kita mengujinya, lebih dari peluang daripada kebutuhan tetapi sudah menangkap beberapa DIA DOA sebelumnya sekarang, dan bukan saya yang melakukannya secara fisik sehingga tidak perlu usaha. Saya untuk itu.

Chopper3
sumber
3
"Uji Kesempatan" masuk akal - mengingat kesempatan saya akan melakukannya. Jika itu akan menunda penyebaran, saya dapat mengambil risiko DIMM yang buruk dan lampu ECC :-)
voretaq7
2
Jika Anda memasukkan tes ke dalam rencana penempatan maka Anda telah membeli waktu sendiri, jika Anda melakukan semuanya secepat mungkin, Anda akan menyiapkan diri untuk dikritik di kemudian hari. Manajemen yang tangguh kapanpun Anda bisa :)
Chopper3
@ Chopper3 Jadi jika Anda membuat kebijakan, lakukan selalu? , tidak pernah? atau melakukannya ketika Anda bisa? .
ewwhite
@ewwhite - Saya akan mengatakan yang terakhir, meskipun kami cenderung merekayasa itu ke dalam rencana penerapan standar, jadi sangat mungkin setiap kali.
Chopper3
11

Yah saya kira itu tergantung pada apa proses Anda. Saya SELALU menjalankan MemTest86 pada memori sebelum saya memasukkannya ke dalam sistem (server atau lainnya). Setelah Anda menjalankan dan menjalankan sistem, masalah yang disebabkan oleh memori yang salah bisa sulit untuk dipecahkan.

Adapun sebenarnya "stress-testing" memori; Saya bahkan belum melihat mengapa ini akan berguna kecuali Anda menguji untuk tujuan overclocking.

Atari911
sumber
Apa yang dikatakan MemTest86 kepada Anda? Apakah Anda menemukan masalah RAM sebelum menginstalnya di server menggunakan metode ini?
ewwhite
4
Saya telah menemukan banyak kesalahan dengan MemTest86 + yang tidak ditemukan oleh diagnosa BIOS dan Windows. Saya sangat merekomendasikannya. Ya, ECC akan menemukan kesalahan yang sama, tetapi memtest akan membantu Anda menemukan semuanya sebelumnya.
Owen Johnson
6
MemTest akan memberi tahu Anda jika ada kekurangan di bagian dalam memori. Ini dilakukan dengan menyimpan pola byte serta set byte acak dalam memori dalam upaya untuk memicu kesalahan. Program ini dapat menjalankan "pass" untuk memberi tahu Anda jika ingatannya bagus tapi saya biasanya menjalankan beberapa pass hanya untuk memastikan. Yang menyenangkan tentang MemTest adalah ia memberi tahu saya jika memori buruk sebelum saya menggunakan sistem. Ini telah memicu RMA berkali-kali dan menyelamatkan saya dari banyak sakit kepala. Setelah mesin dikerahkan rasa sakit di @ss untuk RMA memori.
Atari911
2
@OwenJohnson Secara umum ketika Anda menjalankan MemTest86 (+) Anda berharap untuk memicu kesalahan ECC sebelum Anda memasukkan mesin ke dalam produksi :-)
voretaq7
6

Saya tidak, tetapi saya telah melihat orang yang melakukannya. Saya tidak pernah melihat mereka mendapatkan apa pun darinya, saya pikir itu mungkin mabuk atau takhayul mungkin.

Secara pribadi, saya seperti Anda dalam hal tingkat kesalahan ECC lebih berguna bagi saya - dengan asumsi RAM bukan DOA tetapi kemudian Anda akan tahu itu.

Sirex
sumber
6

Untuk ram non-ECC menjalankan 30 menit pada memtest86 + berguna karena biasanya tidak ada metode yang dapat diandalkan untuk mendeteksi kesalahan bit ketika sistem sedang berjalan.
Skrining biru tidak dianggap sebagai metode yang dapat diandalkan ...
Dan RAM yang sedikit terkelupas sering tidak segera muncul, hanya setelah sistem melihat beberapa memori penuh dan kemudian hanya jika data dalam RAM tersebut adalah kode yang digunakan dan kemudian jatuh. Korupsi data bisa tidak diketahui untuk waktu yang lama.

Untuk ram ECC itu tidak akan melakukan apa pun pengontrol memori itu sendiri tidak akan melakukannya sehingga benar-benar tidak masuk akal. Itu hanya buang-buang waktu saja.

Dalam pengalaman saya, orang-orang yang bersikeras membakar biasanya orang-orang tua yang selalu melakukannya seperti ini dan yang terus melakukannya karena kebiasaan tanpa benar-benar memikirkan hal-hal yang benar.
Atau mereka adalah anak muda yang mengikuti prosedur yang ditentukan yang ditulis oleh orang-orang tua itu.

Tonny
sumber
Pengetahuan buruk, diturunkan dari generasi ke generasi?
ewwhite
@white Ya, sejauh yang saya tahu. Dan saya punya Bsc. dalam teknologi perangkat keras komputer, jadi saya seharusnya tahu apa yang saya bicarakan :-)
Tonny
kecuali untuk semua insiden orang yang benar-benar menemukan kesalahan, seperti yang ditunjukkan di utas. Juga, jika tidak jelas, ada perbedaan dalam mendapatkan bagian-bagian yang ditukar sebelum mengambil server ke dalam produksi atau mengganti ram pada server DB yang berjalan dalam 24x7. Kecuali jika berpura-pura itu adalah "Kesalahan Tumbuh" dan semua orang hanya tua dan melakukan hal-hal pemujaan kargo, tapi itu masih akan menyebabkan kerugian untuk memiliki server prod offline.
Florian Heigl
1
@FlorianHeigl Saya tidak menganjurkan pembakaran dalam RAM demi hal itu, tapi saya tidak akan pernah merekomendasikan untuk memasukkan server ke dalam produksi, tanpa harus diuji stres setidaknya selama 24 jam. RAM biasanya bukan masalah. HDD Flaky, pengontrol RAID, kartu IPMI, catu daya, CPU, VRM ... Saya telah melihat semuanya. (Dan seringkali server selamat dari instalasi awal baik-baik saja. Ini beban dan / atau kesehatan yang melakukannya ketika itu harus benar-benar bekerja.)
Tonny
3

Tergantung.

Jika Anda menggunakan 50.000 RAM baru, dan Anda tahu bahwa perangkat keras ini memiliki tingkat kegagalan 0,01% setelah beroperasi kurang dari sehari, secara statistik harus ada beberapa dari mereka yang akan gagal pada hari pertama. Membakar dimaksudkan untuk menangkap itu. Dengan penyebaran pada skala itu, kegagalan diharapkan, bukan situasi yang luar biasa.

Jika Anda hanya menggunakan beberapa ratusan item saja, statistik kemungkinan besar ada di pihak Anda karena Anda pasti sangat tidak beruntung mendapatkan bagian yang gagal.

Lie Ryan
sumber
Anda benar. Tapi mari kita hadapi itu, kebanyakan dari kita tidak akan pernah melakukan penyebaran sebesar itu. (Kecuali jika Anda sedang membangun pusat data Google baru.) Sebagian besar dari kita biasanya menggunakan paling banyak 5 hingga 10 server secara bersamaan. Yang terbesar yang saya pribadi pernah lakukan adalah 16 ESX node (4x 4-node cluster) yang masing-masing mengambil 8 DIMM. Itu 3 tahun yang lalu dan sejak itu 1 DIMM gagal (2 bulan lalu). Harus mengganti 5 catu daya pada mesin yang sama. 1 pertama setelah seminggu sudah. Tetapi karena ini adalah HP Proliants, kami agak berharap demikian. (HP dan catu daya .. Jangan mulai ...)
Tonny