ZFS pool membaca berurutan lambat


10

Saya memiliki pertanyaan terkait tentang masalah ini, tetapi menjadi terlalu rumit dan terlalu besar, jadi saya memutuskan untuk membagi masalah menjadi NFS dan masalah lokal. Saya juga telah mencoba menanyakan hal ini di milis zfs-mendiskusikan tanpa banyak keberhasilan.

Penyalinan lambat antara direktori NFS / CIFS di server yang sama

Garis Besar: Bagaimana saya mengatur dan apa yang saya harapkan

  1. Saya memiliki kumpulan ZFS dengan 4 disk. 2TB RED dikonfigurasi sebagai 2 mirror yang bergaris (RAID 10). Di Linux, zfsonlinux. Tidak ada cache atau perangkat log.
  2. Data seimbang antar mirror (penting untuk ZFS)
  3. Setiap disk dapat membaca (raw w / dd) pada 147MB / detik secara paralel, memberikan throughput gabungan 588MB / detik.
  4. Saya mengharapkan sekitar 115MB / detik tulis, 138MB / detik baca dan 50MB / detik penulisan ulang data sekuensial dari masing-masing disk, berdasarkan tolok ukur dari disk RED 4TB serupa. Saya berharap tidak kurang dari 100MB / detik membaca atau menulis, karena disk apa pun dapat melakukannya hari ini.
  5. Saya pikir saya akan melihat utilisasi IO 100% pada semua 4 disk ketika membaca beban atau menulis data berurutan. Dan bahwa disk akan mengeluarkan lebih dari 100MB / detik sementara pada pemanfaatan 100%.
  6. Saya pikir pool akan memberi saya sekitar 2x menulis, 2x menulis ulang, dan 4x membaca kinerja lebih dari satu disk - apakah saya salah?
  7. BARU Saya pikir ext4 zvol pada kolam yang sama akan memiliki kecepatan yang sama dengan ZFS

Apa yang sebenarnya saya dapatkan

Saya menemukan kinerja membaca kolam tidak setinggi yang saya harapkan

bonnie ++ benchmark di pool dari beberapa hari yang lalu

Versi 1.97 ------ Output Sekuensial ------ - Input Penting- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Ukuran Mesin K / detik% CP K / detik% CP K / detik% CP K / detik% CP K / detik% CP / detik% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6

Bonnie ++ pada drive RED 4TB tunggal itu sendiri di zpool

Versi 1.97 ------ Output Sekuensial ------ - Input Penting- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Ukuran Mesin K / detik% CP K / detik% CP K / detik% CP K / detik% CP K / detik% CP / detik% CP
igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111.6 8

Menurut ini, kecepatan membaca dan menulis ulang sesuai berdasarkan hasil dari drive RED 4TB tunggal (mereka ganda). Namun, kecepatan baca yang saya harapkan sekitar 550MB / detik (4x kecepatan drive 4TB) dan setidaknya saya berharap sekitar 400MB / detik. Sebaliknya saya melihat sekitar 260MB / detik

Bonnie ++ di kolam dari sekarang, sambil mengumpulkan informasi di bawah ini. Tidak persis sama dengan sebelumnya, dan tidak ada yang berubah.

Versi 1.97 ------ Output Sekuensial ------ - Input Penting- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Ukuran Mesin K / detik% CP K / detik% CP K / detik% CP K / detik% CP K / detik% CP / detik% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256,4 18

zpool iostat saat menulis. Sepertinya saya baik-baik saja.

                                                 bandwidth operasi kapasitas
kumpulan kolam baca baca tulis baca tulis
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
  mirror 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1,60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  mirror 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

zpool iostat selama penulisan ulang. Sepertinya tidak masalah bagi saya, saya pikir .

                                                 bandwidth operasi kapasitas
kumpulan kolam baca baca tulis baca tulis
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 1015 923 125M 101M
  mirror 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24,4M 51,7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306 384 37,8M 45,1M
  mirror 651G 1.18T 510 457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37.8M 43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25.5M 49.6M

Di sinilah saya bertanya-tanya apa yang terjadi

zpool iostat selama membaca

                                                 bandwidth operasi kapasitas
kumpulan kolam baca baca tulis baca tulis
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  mirror 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92,5M 96,8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76,8M 96,8K
  mirror 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95,7M 56,0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74.0M 56.0K

iostat -x selama operasi baca yang sama. Perhatikan bagaimana IO% tidak pada 100%.

Perangkat: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz menunggu r_await w_await svctm% util
sdb 0.60 0.00 661.30 6.00 83652.80 49.20 250.87 2.32 3.47 3.46 4.87 1.20 79.76
sdd 0.80 0.00 735.40 5.30 93273.20 49.20 251.98 2.60 3.51 3.51 4.15 1.20 89.04
sdf 0,50 0,00 656,70 3.80 83196.80 31.20 252.02 2.23 3.38 3.36 6.63 1.17 77.12
sda 0.70 0.00 738.30 3.30 93572.00 31.20 252.44 2.45 3.33 3.31 7.03 1.14 84.24

zpool dan pengaturan dataset uji:

  • atime tidak aktif
  • kompresi tidak aktif
  • ashift adalah 0 (deteksi otomatis - pemahaman saya adalah bahwa ini ok)
  • zdb mengatakan disk semua ashift = 12
  • modul - opsi zfs zvol_threads = 32 zfs_arc_max = 17179869184
  • sync = standar

Edit - 30 Okt 2015

Saya melakukan beberapa pengujian lagi

  • dataset bonnie ++ w / recordsize = 1M = 226MB tulis, 392MB baca jauh lebih baik
  • dataset dd w / record size = 1M = 260MB tulis, 392MB baca jauh lebih baik
  • zvol w / ext4 dd bs = 1M = 128MB tulis, 107MB baca kenapa begitu lambat?
  • proses 2 dataset secara paralel = 227MB tulis, 396MB baca
  • dd direct io tidak membuat perbedaan pada dataset dan pada zvol

Saya jauh lebih bahagia dengan kinerja dengan ukuran catatan meningkat. Hampir setiap file di kolam renang lebih dari 1MB. Jadi saya akan membiarkannya seperti itu. Disk masih belum mendapatkan utilisasi 100%, yang membuat saya bertanya-tanya apakah masih bisa lebih cepat. Dan sekarang saya bertanya-tanya mengapa kinerja zvol sangat buruk, karena itu adalah sesuatu yang saya (ringan) gunakan.

Saya senang memberikan informasi yang diminta dalam komentar / jawaban. Ada juga banyak informasi yang diposting di pertanyaan saya yang lain: Penyalinan lambat antara direktori NFS / CIFS di server yang sama

Saya sepenuhnya sadar bahwa saya mungkin tidak mengerti sesuatu dan bahwa ini mungkin tidak menjadi masalah sama sekali. Terima kasih sebelumnya.

Untuk memperjelasnya, pertanyaannya adalah: Mengapa ZFS pool tidak secepat yang saya harapkan? Dan mungkin ada yang salah?


1
Tidak ada penyetelan, saya curiga ... Apakah Anda menyesuaikan ashift untuk disk Anda? Adakah pengaturan zfs.conf? Apakah atime hidup / mati? Adakah pengaturan sinkronisasi yang aneh?
ewwhite

@ewwhite Saya telah menambahkan beberapa detail pada pertanyaan, terima kasih
Ryan Babchishin

Lihat ini: tomshardware.com/reviews/red-wd20efrx-wd30efrx-nas,3248-5.html drive WD Red memiliki waktu pencarian yang sangat buruk. Mereka mengalir dengan baik, tetapi di bawah penggunaan dunia nyata mereka harus mencari, dan statistik IO Anda menunjukkan cukup operasi IO / detik bahwa waktu pencarian hampir pasti mempengaruhi kinerja Anda. Buat zvol dan gunakan dduntuk melihat kinerja seperti apa yang Anda dapatkan. Anda mungkin juga ingin mencoba IO langsung saat Anda naik ke kecepatan streaming di mana buffering ganda dari caching dapat memengaruhi kinerja. FWIW, 3/4 dari total kinerja teoritis membaca 4-disk mentah baik.
Andrew Henle

(kehabisan ruang) Anda juga memiliki disk yang cukup sehingga operasi IO single-threaded mungkin tidak cukup untuk membuat disk Anda sepenuhnya sibuk. Itu mungkin menjelaskan %utilnomor Anda .
Andrew Henle

@AndrewHenle Terima kasih. Semua itu terdengar sangat masuk akal. Saya akan melihat itu sekarang.
Ryan Babchishin

Jawaban:


10

Saya berhasil mendapatkan kecepatan yang sangat dekat dengan angka yang saya harapkan.

Saya mencari 400MB / detik dan berhasil 392MB / detik . Jadi saya katakan itu adalah masalah yang diselesaikan. Dengan tambahan perangkat cache, saya berhasil membaca 458MB / detik (cache saya percaya).

1. Ini pada awalnya dicapai hanya dengan meningkatkan nilai dataset ZFS recordsizemenjadi1M

zfs set recordsize=1M pool2/test

Saya percaya perubahan ini hanya menghasilkan lebih sedikit aktivitas disk, jadi lebih efisien dan besar sinkron membaca dan menulis. Persis apa yang saya minta.

Hasil setelah perubahan

  • bonnie ++ = 226MB tulis, 392MB baca
  • dd = 260MB tulis, baca 392MB
  • 2 proses paralel = 227MB tulis, baca 396MB

2. Saya berhasil lebih baik ketika saya menambahkan perangkat cache (SSD 120GB). Tulisannya sedikit lebih lambat, saya tidak yakin mengapa.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

Trik dengan perangkat cache adalah untuk mengatur l2arc_noprefetch=0di /etc/modprobe.d/zfs.conf . Ini memungkinkan ZFS untuk cache streaming / data sekuensial. Hanya lakukan ini jika perangkat cache Anda lebih cepat dari array Anda, seperti milik saya.

Setelah mendapat manfaat dari perubahan ukuran record pada dataset saya, saya pikir itu mungkin cara yang mirip untuk menangani kinerja zvol yang buruk.

Saya menemukan beberapa orang yang menyebutkan bahwa mereka memperoleh kinerja yang baik menggunakan volblocksize=64k, jadi saya mencobanya. Tidak berhasil

zfs create -b 64k -V 120G pool/volume

Tapi kemudian saya membaca bahwa ext4 (filesystem yang saya uji dengan) mendukung opsi untuk RAID seperti stridedan stripe-width, yang belum pernah saya gunakan sebelumnya. Jadi saya menggunakan situs ini untuk menghitung pengaturan yang diperlukan: https://busybox.net/~aldot/mkfs_stride.html dan memformat zvol lagi.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Saya berlari bonnie++untuk melakukan tolok ukur sederhana dan hasilnya sangat bagus. Saya tidak memiliki hasil dengan saya sayangnya, tetapi mereka setidaknya 5-6x lebih cepat untuk menulis seingat saya. Saya akan memperbarui jawaban ini lagi jika saya melakukan benchmark lagi.


1
Jika saya dapat memberi Anda +1 ekstra untuk kembali hampir setahun kemudian dan menulis jawaban terperinci seperti itu, saya akan melakukannya. Terima kasih!
Jed Daniels

0

Hasil Anda sangat masuk akal, sementara harapan Anda tidak: Anda melebih-lebihkan peningkatan kinerja baca yang diberikan oleh RAID1 (dan, dengan ekstensi, oleh RAID10). Intinya adalah bahwa mirroring 2 arah memberikan paling banyak 2x kecepatan baca / IOP dari disk tunggal, tetapi kinerja dunia nyata bisa berada di mana saja antara 1x-2x.

Mari kita perjelas dengan sebuah contoh. Bayangkan memiliki sistem dengan mirror 2 arah, dengan masing-masing disk mampu 100 MB / s (berurutan) dan 200 IOPS. Dengan kedalaman antrian 1 (maks satu permintaan tunggal, luar biasa) array ini tidak akan memiliki keuntungan dibandingkan dengan disk tunggal: RAID1 membagi permintaan IO pada antrian dua disk, tetapi tidak memecah satu permintaan tunggal menjadi dua disk (setidaknya, implementasi yang saya lihat berperilaku dengan cara ini). Di sisi lain, jika antrian IO Anda lebih besar (misalnya: Anda memiliki 4/8 permintaan luar biasa), total throughput disk akan jauh lebih tinggi daripada disk tunggal.

Hal serupa dapat dilakukan untuk RAID0, tetapi dalam hal ini yang menentukan peningkatan rata-rata adalah fungsi tidak hanya ukuran antrian, tetapi ukuran permintaan IO juga : jika ukuran IO rata-rata Anda lebih rendah dari ukuran chunk, maka tidak akan bergaris pada dua (atau lebih) disk, tetapi akan dilayani oleh satu disk. Hasil Anda dengan peningkatan ukuran record Bonnie ++ menunjukkan perilaku yang tepat ini: menghilangkan banyak manfaat dari ukuran IO yang lebih besar.

Sekarang harus jelas bahwa menggabungkan dua tingkat RAID dalam array RAID10 tidak akan mengarah ke penskalaan kinerja linear, tetapi menetapkan batas atas untuk itu. Saya cukup yakin bahwa jika Anda menjalankan beberapa instance dd / bonnie ++ (atau gunakan fiountuk secara langsung memanipulasi antrian IO), Anda akan mendapatkan hasil yang lebih sesuai dengan harapan awal Anda, hanya karena Anda akan mengenakan pajak array IO Anda dengan cara yang lebih lengkap ( beberapa permintaan IO berurutan / acak), alih-alih memuatnya dari permintaan IO tunggal berurutan saja.


Harapan saya hampir identik dengan apa yang saya dapatkan - 400MB / detik. Saya mendapatkan 392MB / detik. Tampaknya masuk akal. sangat masuk akal. Saya juga menjalankan banyak proses dd dan bonnie ++ secara paralel dan tidak melihat peningkatan kinerja sama sekali. Anda belum menjelaskan mengapa kinerja zvol sangat buruk.
Ryan Babchishin

Anda mendapatkan 392 MB / s hanya menggunakan Bonnie ++ dengan ukuran rekaman besar (> = 1MB / s), dan saya menjelaskan alasannya. EXT4 melalui ZVOL adalah konfigurasi yang tidak pernah saya uji, jadi saya meninggalkannya untuk dikomentari oleh orang lain.
shodanshok
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.