Ketika datang untuk mengoptimalkan sistem untuk kinerja maksimum, itu bisa sangat mudah untuk membuat kesalahan jika Anda menerapkan praktik orang lain secara sembarangan. Salah satu praktiknya adalah menentukan nobarrier saat memasang sistem file.
Bagaimana catatan ini lahir
Saya bekerja sebagai seorang insinyur di Mail.Ru Cloud Solutions dan terutama menangani semua jenis penyimpanan blok "sekitar dan" di mana letak mesin virtual pengguna kami - dan, oleh karena itu, kasus-kasus menarik sering muncul terkait dengan kinerja dan stabilitas mesin virtual yang berjalan di aplikasi - dan terutama basis data.
Sebagai aturan, dalam hampir setengah dari kasus selama "debriefing" kita melihat hal yang sama - sistem file yang dipasang dengan opsi nobarrier. Dan ketika kami bertanya - "mengapa Anda menulis opsi ini", maka kami hampir selalu mendapatkan salah satu opsi jawaban "Saya diberitahu itu lebih cepat / saya membaca bahwa itu lebih cepat / saya dibentuk seperti itu" - setelah itu kami dengan sopan dan hati-hati mencoba menjelaskan bahwa JADI tidak perlu. Mengapa Karena ini adalah langkah percaya diri pertama di jalan menuju kehilangan data.
Tamasya singkat
Sistem file - strukturnya sangat kompleks dan sangat dimuat. Untuk memastikan kinerja maksimum, caching dan perekaman paralel digunakan secara aktif dalam proses. Dengan demikian, sebagian dari data masuk ke cache dan dibuang kapan pun memungkinkan / diperlukan atau "sesuai permintaan". Penghalang adalah operasi khusus untuk memaksa semua cache dibuang ke disk.
Ketika datang ke database, kita harus yakin bahwa transaksi yang dikonfirmasikan kepada klien (aplikasi klien) telah gigih dan tidak akan hilang, di satu sisi, dan di sisi lain, DBMS aktif menggunakan cache mereka sendiri untuk mencapai kinerja maksimum - dan untuk memastikan konsistensi, penjurnalan digunakan - perubahan ditulis ke log, log “disinkronkan” dan kemudian perubahan ditulis ke data (dan ketika ditulis, ia masuk ke cache). Ketika log penuh, sinkronisasi paksa dilakukan untuk semua data dalam cache dan log mulai terisi kembali.
Sinkronisasi operasi
Ketika sinkronisasi dijalankan, sistem operasi tidak hanya mem-flush cache halaman, tetapi secara default mengirimkan perintah untuk mem-flush semua cache disk (dan, mungkin, melakukan ini berulang kali) - yang disebut
siram . Operasi penyiraman buffer "mahal" dan membutuhkan waktu yang lama - tetapi perlu, karena dalam sistem file urutan penulisan penting - jika dilanggar, maka (misalnya) dapat berubah bahwa ketika reboot tiba-tiba pada file terdapat sampah alih-alih data - karena perangkat memutuskan untuk menyusun ulang catatan. Dan ketika flush secara otomatis mem-flush semua cache - ini memastikan bahwa terlebih dahulu apa yang sebelum flush ditulis, dan hanya kemudian apa yang terjadi setelahnya - yaitu, "penghalang" dibuat membagi entri menjadi "sebelum penghalang" dan "setelah penghalang" (dari sini dan nama "penghalang tulis") - dan ini memungkinkan untuk memastikan bahwa catatan setelah penghalang tidak akan diterapkan lebih awal dari catatan sebelum penghalang.
Efek yang lebih buruk
Opsi nobarrier menonaktifkan pengiriman flush paksa saat sistem file berjalan. Ini mengarah pada fakta bahwa rekaman dapat disusun ulang - dan jika terjadi kegagalan, sistem file (dan umumnya data dalam kasus umum) mungkin tidak konsisten - mari kita ingat apa yang disebutkan dalam paragraf sebelumnya tentang urutan rekaman.
Mengapa opsi ini disertakan? Untuk SSD berbiaya rendah, operasi flush sangat mahal - misalnya, SSD berbiaya rendah (dan banyak yang mahal yang diposisikan sebagai "server") melakukan operasi penulisan 10-20 ribu per detik tanpa flush, dan dengan flush on, turun menjadi 1-2 ribu. Dalam kasus seperti itu, nobarrier memberikan peningkatan kinerja yang signifikan, menciptakan risiko integritas data yang dijelaskan di atas.
Lingkungan virtual
Dalam kasus mesin virtual - jika, misalnya, kita berbicara tentang konfigurasi klasik mesin virtual pada hypervisor Linux, kita memiliki QEMU - sebuah proses yang sebenarnya bertanggung jawab untuk meniru I / O untuk sistem operasi tamu. Dan yang paling penting, jika kita menggunakan disk yang tidak didukung file dalam mesin virtual, maka cache disk virtual tersebut (tiba-tiba!?) Terletak di ruang pengguna - di ruang alamat pada proses QEMU yang sesuai. Dan jika proses ini macet - misalnya, menurut SEGFAULT / SIGSEGV - maka semua cache akan mati bersamanya. Contoh dari driver perangkat blok tersebut adalah driver RBD (Ceph).
Dan bahkan jika Anda tidak menggunakan Ceph tetapi iSCSI / FC, misalnya, tingkat kegagalan tidak hilang - itu hanya bergeser dari QEMU ke sistem operasi host (hypervisor). Hypervisor jatuh - cache halamannya mati (ini berlaku untuk io = 'utas' dalam kombinasi dengan cache = 'writeback' atau cache = 'tidak aman'). Ups
s / Cloud / Alien computer / g
Ketika mesin virtual Anda digunakan di cloud ... Maka Anda tidak tahu bagaimana hypervisor dikonfigurasikan, bagaimana QEMU dikonfigurasikan, driver disk apa yang terlibat, apakah cache halaman host berfungsi, dll., Dan Anda tidak dapat memengaruhi ini dalam sebagian besar kasus. Dan bahkan jika itu cloud Anda - di mana Anda tahu semua ini dan lebih atau kurang mengendalikannya, sama sekali bukan fakta bahwa hypervisor Anda tidak akan "jatuh" - mengubur seluruh cache data.
Ringkasan
Menggunakan nobarrier di cloud berarti Anda kemungkinan besar akan membahayakan data Anda. Apakah Anda yakin ingin mendapatkan peningkatan produktivitas dengan mengorbankan risiko ini?