filesystem untuk jutaan file kecil

44

Sistem file Linux mana yang akan Anda pilih untuk kecepatan terbaik dalam skenario berikut:

seratus juta file
~ Ukuran file 2k rata-rata
> 95% akses baca
akses yang cukup acak
konkurensi tinggi (> 100 proses)

Catatan: File disimpan dalam hierarki pohon yang dalam untuk menghindari direktori besar. Setiap direktori daun berisi sekitar seribu file.

Bagaimana Anda membandingkannya?

linux filesystems benchmark

— manfaat
sumber

3

Ada beberapa info tambahan yang diperlukan. Misalnya, apakah Anda menyimpan semua file dalam direktori datar, atau dalam direktori bersarang (diurutkan)? Ini dapat memiliki dampak kinerja yang dramatis pada waktu akses file. Memilah-milah 100.000.000 entri dalam pengaturan "flat" akan memerlukan overhead yang signifikan terlepas dari jenis FS; kasus terbaik, Anda sedang melihat semacam pohon pencarian, yang masih membutuhkan beberapa pencarian untuk sampai ke file Anda. Jika Anda membagi file ke dalam subdirektori, waktu akses akan secara signifikan dipercepat karena ada lebih sedikit entri untuk dicari di setiap level.

— Avery Payne

Apakah file diakses secara serial atau bersamaan?

— Steve Schnepp

19

Inilah beberapa hasil yang membandingkan semua FSe linux utama dengan bonnie ++ yang dapat Anda gunakan sebagai titik awal.

Dalam hal pencarian acak, Reiser menang, diikuti oleh EXT4, diikuti oleh JFS. Saya tidak yakin apakah ini akan berkorelasi dengan pencarian direktori, tetapi sepertinya itu akan menjadi indikator. Anda harus melakukan tes sendiri untuk itu secara khusus. EXT2 mengalahkan segalanya untuk waktu pembuatan file, kemungkinan karena kurangnya jurnal, EXT4 mengalahkan segalanya kecuali Reiser yang mungkin tidak ingin Anda gunakan karena memiliki status reiser saat ini.

Anda mungkin ingin melihat drive yang mendukung NCQ, dan pastikan instalasi Anda sudah siap untuk menggunakannya. Di bawah pencarian yang berat itu harus memberikan dorongan kecepatan.

Terakhir, pastikan mesin Anda memiliki satu ton ram. Karena file-file tersebut tidak sering diperbarui, linux pada akhirnya akan menyinggahi sebagian besar dari file-file itu untuk ram jika ada ruang kosong. Jika pola penggunaan Anda benar, ini akan memberi Anda dorongan kecepatan besar.

— Andrew Cholakian
sumber

1

masalah Bonnie ++ adalah bahwa hal itu bahkan tidak kasar menguji penggunaan saya skenario

— bene

2

Anda punya poin tentang hal itu bukan pengujian pencarian direktori, tetapi jujur, jika itu choke point Anda, Anda lebih baik membuang data Anda ke database nyata. Filesystem tidak bekerja hampir sama baik pada benda-benda kecil yang paling database yang dirancang untuk menggunakan

— Andrew Cholakian

7

@AndrewCholakian Link sekarang mati.

— Don Scott

8

Saya setuju dengan sebagian besar apa yang dikatakan Andrew, kecuali bahwa saya akan merekomendasikan Reiser4 atau yang lebih lama (tapi lebih baik didukung) ReiserFS . Seperti yang ditunjukkan oleh tes tersebut (dan dokumentasi untuk ReiserFS), tes ini dirancang untuk situasi yang Anda tanyakan (sejumlah besar file kecil atau direktori). Saya telah menggunakan ReiserFS di masa lalu dengan Gentoo dan Ubuntu tanpa masalah.

Mengenai status Hans Reiser, saya tidak melihatnya sebagai masalah dengan kode atau stabilitas Sistem File itu sendiri. Reiser4 bahkan disponsori oleh DARPA dan Linspire, jadi sementara saya setuju bahwa pengembangan lebih lanjut dari Sistem File Reiser tidak ditentukan, saya tidak berpikir bahwa harus menjadi faktor penentu apakah seseorang harus menggunakannya atau tidak.

— Mike
sumber

3

Saya telah menggunakan ReiserFS untuk waktu yang lama. Sebenarnya, saya masih menggunakannya di server Gentoo lama yang belum saya instal ulang. Instalasi ini berusia 4 tahun pada bulan Mei ini. Yang bisa saya katakan adalah bahwa ia melambat secara signifikan. Fenomena itu telah terjadi dari waktu ke waktu pada semua sistem file menggunakan ReiserFS yang sedang aktif membaca + menulis penggunaan pada semua mesin yang memiliki sistem file seperti itu, tidak ada pengecualian - jadi jika Anda ingin menggunakannya selama periode waktu yang lama itu adalah sesuatu yang harus disimpan dalam pikiran. Saya sudah pindah dari itu, menggunakan XFS untuk sistem file besar sekarang.

— Mihai Limbăşan

3

Saya tahu ini bukan jawaban langsung untuk pertanyaan Anda, tetapi dalam kasus ini saya pikir database mungkin lebih cocok untuk meng-host ini. File kecil dapat disimpan dalam format biner dalam tabel database dan diambil pada saat wil. Perangkat lunak yang menggunakan file-file ini harus dapat mendukung ini ...

— Jeroen Landheer
sumber

1

Apa itu sistem file, jika bukan hanya database hirarkis? Proposal Anda menambahkan lapisan abstraksi, kompleksitas, dan perangkat lunak yang mungkin tidak dijamin. Selain itu, pemilik pertanyaan sedang menyelesaikan tugasnya dengan 'UNIX Philosophy' yang saya curigai Anda tidak suka menjadi orang Windows?

— Stu Thompson

3

Pertama-tama, saya tidak menentang Unix atau apapun di area itu. Ada perbedaan besar antara sistem file dan database dan itulah mengapa kedua teknologi dikembangkan. Database dirancang untuk bekerja dengan sejumlah besar entitas kecil, di mana mereka melakukan pekerjaan yang lebih baik daripada kebanyakan sistem file. Saya hanya menunjukkan bahwa mungkin ada jalan lain yang bisa Anda ambil dengan ini.

— Jeroen Landheer

1

Dan jauh lebih mudah untuk "membersihkan / menyedot" file db daripada mendefrag sistem file di linux. Sebagian besar / semua fs tidak menyediakan fungsionalitas itu, mengatakan itu tidak perlu. Memperhatikan komentar Mihai di atas, Anda dapat melihatnya tidak sepenuhnya benar.

— Gringo Suave

3

Seseorang yang berada di Unix StackExchange membuat patokan (dengan sumber) untuk menguji skenario ini saja:

T: Apa sistem file Linux berperforma paling tinggi untuk menyimpan banyak file kecil (HDD, bukan SSD)?

Kinerja baca terbaik tampaknya berasal dari ReiserFS.

— lalu sayang
sumber

Btrfs tampaknya memiliki hasil yang lebih baik atau sebanding dalam segala hal selain hapus. Tapi, seberapa sering Anda menghapus file 300 ribu? Saya suka rf di masa lalu, tetapi btrf mungkin lebih baik untuk masa depan.

— Gringo Suave

3

Dalam pengalaman saya, ext2 berhembus ext4 keluar dari air untuk file kecil. Jika Anda tidak peduli dengan integritas menulis, itu bagus. Sebagai contoh, subversi membuat banyak dan banyak file kecil, yang ext4 dan filesystem lain (XFS) tersedak (menjalankan tugas cron yang mensinkronisasi data ke ext4 dari ext2 setiap setengah jam atau lebih untuk menyelesaikan masalah.)

Menjalankan perintah-perintah ini membuat ext2 lebih cepat (walaupun sebagian besar dari opsi-opsi ini membuat sistem file tidak stabil setelah crash kecuali Anda menjalankan sinkronisasi sebelum crash). Perintah-perintah ini hampir tidak berpengaruh pada ext4 dengan file kecil.

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

— Jason Hall
sumber

1

Saya kira ext3 (atau ext4), mungkin JFS akan menjadi solusi yang bagus. Saya akan berhati-hati dengan ext4 dan btrfs (filesystem yang rumit - bersiaplah dengan cadangan jika Anda ingin menggunakan hal-hal terbaru dan terbaru).

Ada juga berbagai parameter yang dapat Anda atur selama waktu mkfs untuk menyesuaikan sistem file sesuai keinginan Anda.

Saya pasti akan merekomendasikan melawan XFS. Bukan karena itu adalah sistem file yang buruk, tetapi penciptaan / penghapusan adalah operasi yang mahal.

Untuk menghindari masalah dengan pencarian direktori, gunakan skema penamaan yang cerdas, misalnya:

<first letter of id>_<last letter of id>/<id>

atau skema serupa yang lebih rumit. Ini akan mempercepat pencarian direktori Anda dan karenanya kecepatan akses keseluruhan. (Ini trik unix lama, kembali dari V7 saya pikir)

1

apa keuntungan menggunakan huruf pertama dan terakhir dan bukan hanya huruf n pertama?

— bene

itu hanya salah satu skema yang mungkin - apakah itu akan menjadi keuntungan tergantung pada "kunci" yang digunakan untuk pengindeksan. Skema khusus ini saya lihat dirujuk dengan aplikasi yang menyimpan data pada orang-orang dalam organisasi, dan dengan cara ini mereka mendapatkan pengindeksan yang lebih baik. Seperti biasa, Anda perlu disesuaikan dengan data Anda dan kemudian profil sampai Anda menemukan jawaban yang tepat :)

1

Kebanyakan FS akan tersedak dengan lebih dari 65 ribu file dalam sebuah dir, saya pikir itu masih berlaku untuk ext4. Sistem file Reiser tidak memiliki batas itu (orang-orang di mp3.com dibayar untuk memastikan hal itu). Tidak yakin tentang hal lain, tapi itu adalah salah satu skenario penggunaan yang dibuat ReiserFS.

— Ronald Pottol
sumber

1

Ini ReiserFS, bukan RieserFS

— Daniel Rikowski

Akhir pekan ini saya memiliki direktori pada ext4 dengan 10.00000 file di dalamnya. Selama Anda tidak melakukan lsatau menyelesaikan tab itu bekerja cepat. Mungkin karena indeks.

— Ole Tange

ext4 memiliki ekstensi dir_index, yang mempercepat banyak file dalam satu direktori.

— alfonx