Penggunaan O_DIRECT di Linux

Jika pertanyaan ini terlalu berorientasi pada programmer, beri tahu saya. Saya ingin tahu apakah ada orang yang terbiasa dengan flag O_DIRECT untuk pemanggilan sistem open () di Linux 2.6? Linus meremehkan penggunaannya, namun penulisan file berkinerja tinggi tampaknya mengindikasikan penggunaannya. Saya ingin mengetahui pengalaman dan rekomendasi dunia nyata.

Info lebih lanjut: Aplikasi yang saya gunakan memang mempertahankan cache sendiri, dan dengan demikian mencapai rata-rata 5x atau lebih mempercepat. Saat menulis ke file, isi cache harus dituliskan ke cache sistem file, yang tampaknya berlebihan dan menjadi masalah kinerja.

Ok, Anda minta pengalaman, ini membuat pertanyaannya sedikit subjektif dan argumentatif, tapi lumayan.

Linus mengatakan bahwa merujuk pada penggunaan yang biasanya dikaitkan orang dengan O_DIRECT, dan untuk penggunaan itu, IMO Linus sebagian besar benar. Bahkan jika Anda melakukan I / O langsung, Anda tidak dapat mentransfer data ke / dari perangkat langsung ke pernyataan program Anda, Anda memerlukan buffer yang diisi (oleh program atau perangkat) dan ditransfer melalui panggilan sistem ke ujung lainnya. Juga, untuk membuatnya efisien, Anda tidak ingin membaca ulang sesuatu yang baru saja Anda baca, jika Anda membutuhkannya lagi. Jadi, Anda memerlukan semacam cache ... dan itu persisnya yang disediakan kernel tanpa O_DIRECT, cache halaman! Kenapa tidak menggunakannya? Itu juga datang dengan manfaat jika lebih banyak proses ingin mengakses file yang sama secara bersamaan, itu akan menjadi bencana dengan O_DIRECT.

Karena itu, O_DIRECT memiliki kegunaannya: Jika karena alasan tertentu Anda perlu mendapatkan data langsung dari perangkat blok. Itu tidak ada hubungannya dengan kinerja.

Orang-orang yang menggunakan O_DIRECT untuk kinerja biasanya berasal dari sistem dengan algoritma cache halaman yang buruk, atau tanpa mekanisme saran POSIX, atau bahkan orang-orang yang dengan ceroboh mengulangi apa yang dikatakan orang lain. Untuk menghindari masalah ini, O_DIRECT adalah solusinya. Linux, OTOH, memiliki filosofi bahwa Anda harus memperbaiki masalah mendasar yang sebenarnya, dan masalah mendasarnya adalah OS yang melakukan pekerjaan buruk dengan caching halaman.

Saya menggunakan O_DIRECT untuk implementasi sederhana kucing untuk menemukan kesalahan memori di mesin saya. Ini adalah salah satu penggunaan yang valid untuk O_DIRECT. Itu tidak ada hubungannya dengan kinerja.

Sebenarnya, O_DIRECT ini diperlukan untuk menghindari salah satu dari

• cache cache - kadang-kadang Anda tahu bahwa overhead dengan caching tidak masuk akal, misalnya ketika berhadapan dengan file yang sangat besar, katakan 64 GiB ketika hanya ada 2 GiB RAM. File torrent 32 GiB yang pengguna putuskan untuk verifikasi sepertinya bukan kandidat yang baik untuk caching. Itu hanya aktivitas ekstra dengan overhead sendiri. Dan itu dapat menyebabkan beberapa data yang sangat berguna dipangkas dari cache.
• caching ganda - misalnya untuk beberapa RDBMS (untuk menyebutkan MySQL) memungkinkan untuk mendefinisikan cache sendiri. Database seharusnya tahu lebih baik bagaimana cara cache dan apa, dari Memori Virtual kernel yang tidak tahu apa-apa tentang perencanaan SQL dan sebagainya.

- yang tidak baik, seperti yang terlihat. Dan O_DIRECTtidak berarti lebih cepat, sering kali tidak .

Perhatikan bahwa menggunakan O_DIRECTkemungkinan gagal di kernel yang lebih baru dengan sistem file yang lebih baru. Lihat laporan bug ini misalnya. Jadi tidak hanya penggunaannya yang sering meragukan, kemungkinan tidak akan berfungsi sama sekali pada generasi distribusi Linux yang akan datang. Jadi saya tidak akan bertaruh kinerja kode saya di atasnya, bahkan jika Anda dapat membuktikan bahwa itu mungkin memiliki manfaat.

Ini banyak hubungannya dengan kinerja.

Contoh yang menarik adalah di mongodb menggunakan mesin mmap. O_DIRECT paling baik digunakan, seperti yang orang lain nyatakan, di mana data tidak mungkin dibaca untuk beberapa waktu. Dalam mongodb, jurnal basis data ditulis menggunakan O_DIRECT sedangkan penulisan data dan indeks ditangani oleh mekanisme cache halaman (pdflush) karena, meskipun O_DIRECT menawarkan lebih sedikit bandwidth, itu juga berarti lebih sedikit latensi, dan karenanya mengurangi kehilangan data jika terjadi pemadaman yang tak terduga (kernel panik, disk atau listrik mati). Perhatikan bahwa masih ada buffering sebelum penulisan O_DIRECT berkomitmen untuk penyimpanan non-volatil, ini hanya mengurangi kehilangan data.

Fitur penting lainnya dari O_DIRECT adalah ia memberikan kontrol lebih besar atas urutan penulisan. Sekali lagi itu tidak menjamin urutan penulisan (kecuali Anda memiliki pengontrol caching disk yang tidak mudah menguap dan menggunakan penjadwal fifo, tetapi ini memiliki komplikasinya sendiri). Oleh karena itu walaupun mysql menggunakan O_DIRECT untuk data / indeks dan juga penjurnalannya, ia dapat berharap bahwa yang terakhir biasanya akan dikomit terlebih dahulu.

Tetapi penting untuk diingat bahwa O_DIRECT merusak keadilan dalam alokasi sumber daya. Salah satu alasan aplikasi Anda dipercepat adalah karena memperlambat hal-hal lain.

Berkaitan dengan apa yang sudah dikatakan @Juliano.

Checkout posix_fadvisejika masalah sebenarnya adalah perilaku yang salah dari algoritma cache sistem file yang mendasarinya, Anda dapat mencoba memberikan saran, bagaimana Anda akan menggunakan sistem file. Untuk fs yang diterapkan dengan baik, harus memberikan peningkatan kinerja. (Berikut ini tautan ke topik lain yang menyentuh pertimbangan serupa /programming//a/3755818/544721 )