Disk SATA yang menangani caching tulis dengan benar?


15

Sangat umum untuk melihat saran untuk menonaktifkan cache tulis pada disk individual yang digunakan untuk basis data karena jika tidak, beberapa disk akan mengakui penulisan yang belum sampai ke permukaan disk.

Ini menyiratkan bahwa beberapa disk tidak mengakui penulisan sampai mereka telah sampai ke permukaan disk (Perbarui: atau bahwa mereka melaporkan secara akurat ketika diminta untuk membersihkan cache. Di mana saya dapat menemukan disk tersebut, atau di mana saya dapat mencari informasi yang berwenang di mana menemukan disk tersebut?

Saya menyiapkan beberapa server DB yang benar-benar akan mendapat manfaat dari menggunakan cache tulis, tetapi aplikasi ini sensitif terhadap harga dan saya lebih suka tidak menggandakan biaya subsistem disk saya untuk beberapa pengontrol RAID caching karena saya tidak memiliki informasi yang cukup untuk tahu apakah saya bisa mempercayai cache di setiap drive.


linux memungkinkan cache tulis dinonaktifkan pada drive dengan drive melalui hdparam. Untuk drive SATA, saya percaya ini harus ditulis ulang untuk diterapkan pada setiap restart. Saya mungkin pergi ke sana jika saya masih bisa memenuhi persyaratan perf kami tanpa menggunakan pengontrol serangan baterai yang didukung. Saya lebih suka menggunakan perangkat lunak RAID bila memungkinkan karena lebih sederhana dan lebih murah. Either way, saya pasti akan memiliki UPS.
eas

Jawaban:


15

Secara umum, sebagai jawaban langsung untuk pertanyaan Anda, saya tidak mengetahui adanya merek utama drive SATA yang drive itu sendiri memiliki bug relatif terhadap operasi yang tepat dengan caching diaktifkan. Yaitu, dari perspektif drive saja, drive melakukan apa yang seharusnya dilakukan dari perspektif caching. Saya juga akan mencatat bahwa bahkan ketika menulis caching yang diaktifkan, bahwa penundaan dari disk menulis di kabel SATA ke media berputar secara fisik yang diperbarui masih sangat singkat (~ 50 sampai 100ms biasanya). Ini tidak seperti data cache kotor akan hanya duduk di sana selama beberapa detik ..... drive terus mencoba untuk mendapatkan data kotor dari cacheke media fisik secepat mungkin. Ini bukan hanya masalah keamanan data, tetapi salah satu dari siap untuk menerima penulisan di masa depan tanpa penundaan (yaitu: menulis posting).

Masalah yang muncul ketika caching diaktifkan adalah bahwa urutan penulisan ke drive melalui kabel SATA dan urutan penulisan ke media putar tidak sama. Ini tidak pernah dapat menyebabkan masalah KECUALI Anda kehilangan daya atau kerusakan sistem sebelum semua konten cache masuk ke disk. Mengapa? ->

Masalah yang dapat muncul di sini adalah relatif terhadap kekokohan transaksi dari sistem file dan / atau isi file database untuk penulisan yang rusak. Akibatnya, mereka yang berpotensi kehilangan aturan menulis secara teoritis dapat merusak integritas logika transaksi yang seharusnya dijamin oleh disk menulis yang terjadi dalam urutan yang sangat spesifik kepada media.

Sekarang, tentu saja, para perancang sistem file, basis data, pengontrol RAID, dll. Menyadari (atau tentunya harus sadar) tentang fenomena ini relatif terhadap penulisan caching. Tembolok tulis sangat diinginkan dari sudut pandang kinerja di sebagian besar skenario tipe I / O akses acak. Faktanya, menyediakan caching tulis adalah elemen kunci untuk dapat memiliki manfaat nyata bagi Antrian Perintah Asli ( NCQ) yang lebih canggih) yang didukung pada SATA yang lebih baru dan beberapa generasi terakhir implementasi PATA. Jadi, untuk menjamin pesanan ke media fisik pada saat-saat kritis tertentu, sistem file dan / atau aplikasi, dll. Secara khusus dapat meminta flush dari cache tulis ke media. Pada penyelesaian permintaan sinkronisasi ini - semua yang tertunda dari (berpotensi) buffer file, cache disk OS, cache disk fisik dll. Sebenarnya keluar pada media sesuai desain sistem transaksi pada operasi kritis yang tepat. Artinya, ini terjadi dengan benar jika pemrogram membuat panggilan yang tepat di bagian atas DAN setiap elemen dari rangkaian perangkat lunak dan perangkat keras ini melakukan tugasnya dengan benar. yaitu: Tidak ada bug dalam hal ini di drive, pengontrol RAID, driver disk, cache OS, sistem file, mesin database, dll. Ini adalah banyak perangkat lunak yang semuanya harus berfungsi dengan benar. Selain itu, memverifikasi kebenaran dalam hal ini sangat sulit karena dalam hampir semua situasi biasanya urutan penulisan tidak masalah sama sekali .... dan kegagalan daya dan skenario kerusakan adalah tes sulit untuk dibangun. Jadi, pada akhirnya "mematikan cache tulis" pada satu atau lebih dari berbagai lapisan dan / atau makna istilah ini .... memiliki reputasi "memperbaiki" jenis masalah tertentu. Akibatnya, mematikan perilaku cache tulis dari pengontrol RAID atau Cache Disk OS, atau Drive, dll. Adalah menghindari satu atau lebih bug dalam sistem ..... dan sumber pengetahuan tersebut. dan kegagalan daya dan skenario kerusakan adalah tes sulit untuk dibangun. Jadi, pada akhirnya "mematikan cache tulis" pada satu atau lebih dari berbagai lapisan dan / atau makna istilah ini .... memiliki reputasi "memperbaiki" jenis masalah tertentu. Akibatnya, mematikan perilaku cache tulis dari pengontrol RAID atau Cache Disk OS, atau Drive, dll. Adalah menghindari satu atau lebih bug dalam sistem ..... dan sumber pengetahuan tersebut. dan kegagalan daya dan skenario kerusakan adalah tes sulit untuk dibangun. Jadi, pada akhirnya "mematikan cache tulis" pada satu atau lebih dari berbagai lapisan dan / atau makna istilah ini .... memiliki reputasi "memperbaiki" jenis masalah tertentu. Akibatnya, mematikan perilaku cache tulis dari pengontrol RAID atau Cache Disk OS, atau Drive, dll. Adalah menghindari satu atau lebih bug dalam sistem ..... dan sumber pengetahuan tersebut.

Bagaimanapun, kembali ke inti pertanyaan: Di bawah SATA, penanganan spesifik semua perintah baca / tulis disk dan perintah cache flush didefinisikan dengan baik oleh spesifikasi SATA . Selain itu, produsen drive harus memiliki dokumentasi terperinci untuk setiap model drive atau keluarga drive yang menggambarkan penerapannya dan kepatuhan terhadap aturan ini seperti contoh ini untuk Seagate Barracuda drive . Khususnya, lihat detail FITUR SET SATAperintah yang mengontrol mode operasional drive dan secara khusus opsi 82h dapat digunakan untuk menonaktifkan caching disk pada level drive karena defaultnya adalah caching tulis diaktifkan pada semua drive yang saya ketahui. Jika Anda benar-benar ingin menonaktifkan cache, perintah ini harus dilakukan pada awal setiap drive reset atau power up dan biasanya di bawah kendali driver disk untuk sistem operasi Anda. Anda mungkin dapat mendorong driver OS Anda untuk mengatur mode ini melalui IOCTL dan / atau tipe Pengaturan Registri, tetapi ini sangat bervariasi.


5
Satu catatan editorial untuk jawaban saya: Hardware RAID Controllers terkenal buggy relatif terhadap banyak masalah termasuk masalah relatif terhadap implementasi internal mereka dari caching tulis. Saya tidak tahu mengapa, tetapi pengontrol RAID yang berbicara secara anekdot tampaknya merupakan beberapa perangkat lunak paling bermasalah yang pernah ditulis dalam hal sesuatu yang telah digunakan secara luas. Itu pasti membayar untuk menggunakan perangkat keras RAID yang sangat utama, mapan dan banyak digunakan dari vendor yang sangat terkemuka ..... dan bahkan patch untuk masalah non-sepele tampaknya terlalu sering!
Tinggi Jeff

Terima kasih Jeff. Saya sudah banyak membaca hal ini, dan saya sama bingungnya dengan saya. Saya pikir masalah yang sedang saya perjuangkan sekarang berkaitan dengan "tulis hambatan" yang memungkinkan aplikasi dan sistem file untuk menginstruksikan lapisan blok untuk menjamin pemesanan tulis yang tepat menggunakan berbagai mekanisme yang tersedia. Sayangnya, ada segala macam masalah dengan implementasi hambatan. LVM, untuk satu hal, tampaknya tidak mendukung mereka, bahkan jika perangkat yang mendasarinya melakukannya. Juga, menurut saya sysadmin harus memiliki opsi untuk memiliki fsync memaksa flush cache drive
eas

@ Eas - Istilah "tulis hambatan" yang Anda rujuk saya asumsikan adalah mekanisme dasar yang sama yang saya sebut "sinkronisasi" atau "siram" dari cache di jawaban saya di atas. Untuk maksud Anda, ini dapat dimulai pada berbagai lapisan di "tumpukan" akses file. Untuk membangun penghalang tulis yang benar, ia harus mempengaruhi semua lapisan yang memiliki data tulis yang tertunda (yaitu: cache kotor atau buffer tulis-balik) ke media fisik untuk benar-benar berfungsi sebagaimana dimaksud. Tautan apa pun yang terputus dalam rantai itu adalah yang menimbulkan masalah potensial saat penulisan diatur ulang.
Tall Jeff

Disk dapat menunda penulisan ke media selama beberapa detik, tentu saja jika ada banyak penulisan lebih lanjut yang melimpahi cache disk, itu akan memaksa penulisan ke media. NCQ tidak benar-benar membutuhkan cache tulis, masih dapat memiliki banyak perintah tulis dan baca yang tertunda dan mengeluarkannya dalam urutan yang menurut disk akan mendapatkan kinerja terbaik, juga dengan NCQ tidak ada artinya pada urutan penulisan yang membuat filesystem dan database perlu menggunakan hambatan IO.
Baruch Even

3

Sudah pengalaman saya bahwa controller disk caching yang didukung baterai akan menonaktifkan cache di drive. Saya tidak mengetahui cara untuk menonaktifkan cache pada disk sebaliknya. Bahkan jika Anda dapat menonaktifkan cache di-disk, kinerja akan sangat menderita.

Untuk optoin berbiaya rendah, Anda dapat menggunakan UPS murah yang dapat memberi sinyal sistem Anda untuk shutdown yang teratur.


Komentar saya di atas seharusnya ditambahkan di sini. Saya masih mempelajari situs ini.
eas

Beberapa pengontrol RAID menonaktifkan cache on-disk sepanjang waktu, beberapa tidak dan beberapa memiliki pengaturan. Perilaku ini secara mendasar tergantung pada seperti apa implementasi strategi caching pengontrol RAID. Dalam beberapa implementasi, mereka benar-benar ingin mengontrol perintah tulis ke disk .... dan yang lain kurang penting. Saya menyinggung beberapa masalah di sini dalam jawaban saya.
Tinggi Jeff

Dalam serangkaian kecil tes yang diakui (pengontrol RAID LSI 9261, SATA, NL SAS, dan drive SAS), saya menemukan bahwa mengaktifkan cache tulis drive saat drive terhubung ke pengontrol RAID dengan cache yang didukung oleh adonan / kapasitas, tidak ada bedanya dengan kinerja berulang-ulang hanya memiliki cache pengontrol RAID. Saya belum akan mengatakan ini adalah aturan yang keras dan cepat, tetapi jelas bagi saya bahwa pengontrol RAID yang menonaktifkan cache drive belum tentu menjadi masalah.
Daniel Lawson

2

Saya menggunakan sistem RAID dengan supercapacitor daripada baterai untuk mempertahankan cache. Baterai aus, harus dipantau, harus diganti dan menunjukkan titik kegagalan potensial dalam hal tersebut. Kapasitor mengisi daya pada saat startup, membersihkan cache ketika daya dari UPS gagal, bertahan hampir selamanya, tidak memerlukan pemantauan, dll. Namun, kecuali Anda menjalankan bisnis di garis kemiskinan (tidak jarang hari ini) Anda harus memiliki UPS dan perangkat lunak yang mematikan sistem dengan bersih pada kegagalan - Saya biasanya memberikannya 5-15 menit (tergantung pada beban UPS dan oleh karena itu baterai tersedia) sebelum shutdown jika daya kembali menyala.

Selama badai, Anda mungkin (atau mungkin memiliki - sistem daya menjadi lebih baik) melihat lampu berkedip, kadang-kadang sebelum mereka padam. Ini adalah perangkat yang disebut recloser. Itu adalah pemutus sirkuit yang ketika tersandung mencoba untuk menutup sakelar yang terbuka seandainya kelebihan beban bersifat sementara, yang kebanyakan adalah. Jika gagal untuk tetap tertutup setelah, katakan tiga kali mencoba, itu tetap terbuka. Pria malang itu harus keluar dalam hujan dan menghadapinya. Jangan merasa kasihan padanya, sementara hanya membuat dua kali apa yang Anda dan saya lakukan dan dua kali bahwa jika lembur, itu pekerjaan yang berbahaya.


2

Salah satu kesalahpahaman jika disk menulis kembali cache adalah bahwa mereka hanya kehilangan data daya yang hilang. Ini tidak selalu terjadi, terutama pada perangkat sATA. Jika perangkat sATA memiliki kesalahan padanya (seperti bug FW kasus atau bug pengontrol) dan me-reset atau diatur ulang secara eksternal, tidak ada jaminan bahwa data dalam cache write-back masih tersedia setelah hang.

Ini dapat menyebabkan skenario di mana perangkat memiliki kesalahan sementara, akan direset, kehilangan data terjadi dalam hilangnya cache kotor, dan ini diam di atas tingkat blok driver.

Lebih buruk lagi, menonaktifkan cache drive melalui alat OS juga akan hilang pada pengaturan ulang perangkat, sehingga bahkan jika perangkat memiliki cache yang dinonaktifkan pada awal hari, jika perangkat diatur ulang, itu akan mengaktifkan kembali cache tulis-kembali. Di reset lain, perangkat kemudian akan kehilangan data.

Drive SCSI / SAS dan beberapa drive sATA memiliki kemampuan untuk menyimpan status profil write-back untuk memastikan bahwa seluruh pengaturan ulang properti tidak hilang - tetapi dalam praktiknya ini jarang digunakan.

Pengontrol RAID yang mengintegrasikan lapisan blok ke dalam lapisan atas dapat melihat pengaturan ulang drive dan menonaktifkan cache tulis kembali - tetapi pengontrol sATA dan SAS standar tidak akan melakukan ini.

Batasan ini juga berlaku untuk FITUR SET lainnya dan parameter serupa yang dikonfigurasi untuk kinerja dan keandalan.


1

Seperti yang Anda katakan, pengontrol RAID yang didukung baterai yang benar akan mahal, tetapi Anda dapat menemukan pengontrol Dell Perc5 / i di eBay seharga £ 100 ($ 150) dan terutama dengan RAID5 kecepatan pengontrol seperti Perc5 / i akan memukau Anda. Saya memiliki beberapa server dengan perc5 / is dan enam disk array RAID5, dan mereka adalah di antara disk tercepat yang pernah saya lihat. Khusus untuk aplikasi basis data, cakram cepat akan sangat meningkatkan kinerja.

Saya akan menggigit peluru dan membeli kontroler RAID.

JR


1

Sejauh yang saya mengerti, fsync () faking adalah properti pengontrol RAID yang didukung baterai, bukan drive. Pengontrol RAID berisi baterai yang dapat memberi daya pada cache tulis hingga daya dipulihkan ke drive dan penulisan dapat dilakukan dengan aman ke disk. Ini memungkinkan pengontrol untuk segera kembali ke OS, karena membuat beberapa tingkat jaminan bahwa penulisan akan ditulis ke disk.

Perlu dicatat, jika cache writeback cache terisi, write akan memblokir sampai cache telah ditulis kembali ke drive. Ini berarti cache umumnya tidak seefektif di bawah menulis berkelanjutan.

Berapa banyak IOPS yang dibutuhkan aplikasi Anda? Apakah Anda yakin bahwa Anda dibatasi oleh cache tulis drive, atau bahwa kecil (dibandingkan dengan memori server Anda) pada drive akan bermanfaat?


Pengujian yang saya lakukan sekarang adalah untuk menentukan amplop kinerja aplikasi kami sehingga kami dapat mengetahui cara terbaik untuk memperbesar dan memperkecil. Cache drive mungkin relatif kecil, tetapi dengan caching tulis di atasnya memberikan drive kemampuan untuk menyusun ulang penulisan (bila perlu), yang sepertinya dapat menggandakan throughput penulisan berkelanjutan.
eas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.