Kinerja ZFS: apakah saya perlu menjaga ruang kosong di kolam atau sistem file?

Saya tahu bahwa kinerja ZFS sangat tergantung pada jumlah ruang kosong:

Jaga ruang kolam di bawah pemanfaatan 80% untuk menjaga kinerja kolam. Saat ini, kinerja kumpulan dapat menurun ketika kumpulan sangat penuh dan sistem file sering diperbarui, seperti pada server surat yang sibuk. Kumpulan lengkap dapat menyebabkan penalti kinerja, tetapi tidak ada masalah lain. [...] Perlu diingat bahwa bahkan dengan sebagian besar konten statis di kisaran 95-96%, menulis, membaca, dan kinerja resilver mungkin akan menderita. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Sekarang, anggaplah saya memiliki kumpulan raidz2 10T hosting sistem file ZFS volume. Sekarang saya membuat sistem file anak volume/testdan memberikan reservasi 5T.

Kemudian saya me-mount kedua sistem file per NFS ke beberapa host dan melakukan beberapa pekerjaan. Saya mengerti bahwa saya tidak dapat menulis volumelebih dari 5T, karena 5T yang tersisa disediakan untuk volume/test.

Pertanyaan pertama saya adalah, bagaimana kinerja turun, jika saya mengisi volumemount point saya dengan ~ 5T? Akankah itu jatuh, karena tidak ada ruang kosong dalam sistem file itu untuk copy-on-write ZFS dan hal-hal meta lainnya? Atau apakah akan tetap sama, karena ZFS dapat menggunakan ruang kosong di dalam ruang yang disediakan untuk volume/test?

Sekarang pertanyaan kedua . Apakah ada bedanya, jika saya mengubah pengaturan sebagai berikut? volumesekarang memiliki dua sistem file, volume/test1dan volume/test2. Keduanya diberi reservasi 3T masing-masing (tetapi tidak ada kuota). Asumsikan sekarang, saya menulis 7T ke test1. Apakah kinerja kedua sistem file akan sama, atau akan berbeda untuk setiap sistem file? Apakah akan jatuh, atau tetap sama?

Terima kasih!

Iya. Anda perlu menjaga ruang kosong di kolam renang Anda. Ini terutama untuk tindakan copy-on-write dan snapshot. Kinerja menurun pada pemanfaatan sekitar 85%. Anda bisa naik, tetapi ada dampak yang pasti.

Jangan macam-macam dengan pemesanan. Apalagi dengan NFS. Itu tidak perlu. Mungkin untuk zvol, tetapi tidak untuk NFS.

Saya tidak melihat kebingungan. Jika Anda memiliki 10T, Jangan gunakan lebih dari 85% darinya. Ukuran saham Anda dengan tepat, menggunakan kuota untuk membatasi penggunaannya. Atau jangan gunakan kuota apa pun dan pantau keseluruhan penggunaan kumpulan Anda .

Penurunan kinerja terjadi ketika zpool Anda sangat penuh atau sangat terfragmentasi. Alasannya adalah mekanisme penemuan blok gratis yang digunakan dengan ZFS. Tidak seperti sistem file lain seperti NTFS atau ext3, tidak ada bitmap blok yang menunjukkan blok mana yang ditempati dan mana yang gratis. Sebagai gantinya, ZFS membagi zvol Anda menjadi (biasanya 200) area yang lebih besar yang disebut "metaslab" dan menyimpan AVL-tree ¹ dari informasi blok gratis (peta ruang) di setiap metaslab. Pohon AVL yang seimbang memungkinkan pencarian yang efisien untuk blok yang sesuai dengan ukuran permintaan.

Meskipun mekanisme ini telah dipilih karena alasan skala, sayangnya itu juga menjadi rasa sakit ketika tingkat fragmentasi dan / atau pemanfaatan ruang yang tinggi terjadi. Segera setelah semua metaslab membawa sejumlah besar data, Anda mendapatkan sejumlah besar area kecil blok bebas sebagai lawan dari sejumlah kecil area besar saat pool kosong. Jika ZFS kemudian perlu mengalokasikan 2 MB ruang, ia mulai membaca dan mengevaluasi peta ruang semua metaslab untuk menemukan blok yang sesuai atau cara untuk memecah 2 MB menjadi blok yang lebih kecil. Ini tentu saja membutuhkan waktu. Yang lebih buruk adalah kenyataan bahwa itu akan menghabiskan banyak biaya operasi I / O karena ZFS memang akan membaca semua peta ruang dari disk fisik . Untuk semua tulisan Anda.

Penurunan kinerja mungkin signifikan. Jika Anda menyukai gambar-gambar cantik, lihat posting blog di Delphix yang memiliki beberapa nomor yang diambil dari kumpulan zfs (terlalu disederhanakan tetapi belum valid). Saya tanpa malu-malu mencuri salah satu grafik - lihat garis-garis biru, merah, kuning, dan hijau dalam grafik ini yang masing-masing mewakili kumpulan pada 10%, 50%, 75%, dan 93% kapasitas ditarik terhadap throughput penulisan di KB / s sementara menjadi terfragmentasi dari waktu ke waktu:

Perbaikan cepat & kotor untuk ini secara tradisional telah menjadi mode debugging metaslab (hanya masalah echo metaslab_debug/W1 | mdb -kwsaat run-time untuk langsung mengubah pengaturan). Dalam hal ini, semua peta ruang akan disimpan dalam RAM OS, menghapus persyaratan untuk I / O yang berlebihan dan mahal pada setiap operasi penulisan. Pada akhirnya, ini juga berarti Anda membutuhkan lebih banyak memori, terutama untuk kolam besar, jadi itu adalah semacam RAM untuk penyimpanan kuda-perdagangan. Kolam 10 TB Anda mungkin akan dikenakan biaya 2-4 GB memori ² , tetapi Anda akan dapat mengarahkannya ke 95% dari pemanfaatan tanpa banyak kesulitan.

¹ ini sedikit lebih rumit, jika Anda tertarik, lihat posting Bonwick di peta luar angkasa untuk detailnya

² jika Anda memerlukan cara untuk menghitung batas atas memori, gunakan zdb -mm <pool>untuk mengambil jumlah yang segmentssaat ini digunakan di setiap metaslab, bagilah dengan dua untuk memodelkan skenario terburuk (setiap segmen yang ditempati akan diikuti oleh yang gratis ), kalikan dengan ukuran rekaman untuk simpul AVL (dua penunjuk memori dan nilai, mengingat 128-bit sifat zfs dan pengalamatan 64-bit akan berjumlah hingga 32 byte, meskipun orang tampaknya secara umum mengasumsikan 64 byte untuk beberapa alasan).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Referensi: garis besar dasar terdapat dalam posting ini oleh Markus Kovero di milis zfs-membahas , meskipun saya percaya dia membuat beberapa kesalahan dalam perhitungannya yang saya harap telah diperbaiki di tambang saya.