Mengapa ada perbedaan kecepatan tulis antara dd, cp, rsync dan macOS Finder ke drive SMB3?

Tl; dr - Kami tidak dapat menemukan alasan untuk kecepatan tulis terbatas 60 MB / detik untuk NAS kami melalui SMB dan AFP dari dua klien Mac yang berbeda. Sebagai perbandingan: Laptop Windows 7 lama di jaringan yang sama menulis stabil 100 MB / detik.

Jika Anda membaca pertanyaan ini untuk pertama kalinya, silakan lewati bagian Pembaruan 4 . rsyncadalah alasan utama untuk kecepatan rendah, meskipun kami tidak mengerti mengapa (untuk satu file!).

Pertanyaan Asli: Temukan bottleneck kecepatan SMB3 / NAS dengan Mac OS 10.11.5 dan di atasnya

Kami menguji melalui rsync --progress -a /localpath/test.file /nas/test.filepada macOS dan info salinan Windows

NAS adalah DS713 + yang menjalankan DSM 6.0.2 mereka saat ini (diuji dengan 5.x juga), dengan dua HGST Deskstar NAS SATA 4TB (HDN724040ALE640) dalam RAID1 dengan hanya komponen ethernet gigabit dan kabel ethernet baru (setidaknya Cat5e).

Klien Mac pertama hanya menghasilkan 20 MB / detik. Tetapi menerapkan signing_required=noperbaikan (dijelaskan di sini ) mendorong kecepatan tulis ke 60 MB / detik melalui SMB2 dan SMB3. AFP juga memberikan sekitar 60 MB / detik. Hasilnya bervariasi sekitar 5 MB / detik tergantung pada protokol dan (Mac) klien.

Apa yang sudah kami coba:

Jaringan

1. Menguji kinerja jaringan melalui iperf3. Hasil: 926 Mbit / s. Kelihatan bagus.
2. Mencoba Dual Link Aggregation / antarmuka jaringan terikat. Tidak ada perubahan.
3. Peningkatan MTU menjadi 6000 dan 9000. Tidak ada perubahan.
4. Memeriksa semua kabel. Semua baik-baik saja setidaknya Cat5e, dalam kondisi baik.

Disk

1. Diperiksa SMART Terlihat sehat.
2. Diuji kecepatan tulis langsung ke disk dengan dd if=/dev/zero of=write.test bs=256M count=4berbagai bsdan countpengaturan (128/8, 512M / 2, 1024/1). Hasil: sekitar 120 MB / s (tergantung pada ukuran / jumlah blok)

SMB / AFP

1. SMB2 dengan Benchmarked, SMB3, dan AFP saling bertentangan Hampir sama.
   Lihat pembaruan di bawah ini: Metode yang digunakan salah untuk mengesampingkan implementasi SMOS dari macOS. SMB pada Windows lebih cepat, pengaturan SMB baru yang datang dengan macOS 10.11 dan 10.12 mungkin menjadi alasannya.
2. Mencoba mengubah pengaturan SMB, termasuk opsi soket (mengikuti instruksi ini )
3. Mencoba versi berbeda dari pengaturan ack tertunda dan rsync --sockopts=TCP_NODELAY(komentar)

Tidak ada perubahan kecepatan tulis yang signifikan. Kami memeriksa ulang bahwa konfigurasi benar-benar dimuat dan kami mengedit smb.conf yang tepat .

Sistem

1. Menonton CPU dan RAM. Tidak ada yang maksimal. CPU sekitar 20%, RAM sekitar 25% saat transfer.
2. Diuji NAS yang sama dengan DSM 5.xx dalam pengaturan hampir out-of-the-box. Tidak ada perangkat lunak tambahan yang diinstal. Catatan: Kami memiliki dua ini di lokasi yang berbeda. Mereka sinkron melalui CloudSync milik Synology. Hasil yang sama
3. Nonaktifkan semua yang tidak perlu yang dapat menarik sumber daya sistem.

Kami pikir ini adalah pengaturan yang agak default, tidak ada adaptasi mewah, klien atau komponen jaringan. Menurut metrik yang diterbitkan Synology, NAS harus melakukan 40 MB / s hingga 75 MB / s lebih cepat. Tapi kami tidak dapat menemukan hambatannya.

Klien / NAS

Klien Mac adalah MacPro 5,1 (NIC berkabel standar, menjalankan 10.12.3 (16D32)) dan MacBookPro10, 1 (adaptor jaringan Thunderbolt, menjalankan 10.11.6) hanya berjarak sekitar 2 m dari kabel NAS, berjalan di atas yang sama gigabit beralih sebagai laptop Windows dalam ujian.

Kami memiliki dua NAS ini di lokasi yang berbeda dan hasilnya identik. Detik NAS adalah kurang lebih default pabrik (bahkan perangkat lunak pihak ketiga tidak diinstal). Hanya dua RAID1, disk berformat EXT4 yang disinkronkan ke NAS lain melalui Synology CloudSync. Kami telah pergi sejauh menghubungkan langsung ke NAS tanpa saklar, hasil yang sama.

Pembaruan Penting

Metode yang digunakan untuk mengesampingkan implementasi SMB dari macOS / OS X salah. Saya mengujinya melalui mesin virtual, dengan asumsi akan menggunakan versi SMB sendiri, tapi jelas lalu lintas diserahkan ke macOS, berjalan melalui versi SMB-nya.

Menggunakan laptop Windows Sekarang saya sudah bisa mencapai rata-rata 100 MB / s. Menunjukkan implementasi / pembaruan SMB yang datang dengan 10.11 dan 10.12 dapat menyebabkan kinerja yang buruk. Bahkan jika signing_requireddiatur ke no.

Akan lebih bagus jika seseorang dapat menunjukkan beberapa pengaturan lebih lanjut yang mungkin telah berubah dengan pembaruan dan dapat mempengaruhi kinerja.

Perbarui 2 - wawasan baru

AndrewHenle menunjukkan dalam komentar bahwa saya harus menyelidiki lalu lintas secara rinci menggunakan Wireshark untuk wawasan lebih lanjut.

Karena itu saya menjalankan sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpNAS, sambil mentransfer dua file uji satu dengan 512 MB dan satu dengan 1 GB. Dan memeriksa tempat pembuangan sampah dengan Wireshark.

Apa yang kutemukan:

1. Baik OS X dan Windows tampaknya menggunakan SMB2 meskipun SMB3 diaktifkan pada NAS (setidaknya menurut Wireshark).
2. OS X tampaknya tetap dengan MTU . Paket-paket tersebut memiliki 1514 byte yang mengarah ke lebih banyak jaringan dan mengirimkan paket (terlihat di dump).
3. Windows tampaknya mengirim paket hingga 26334 byte (jika saya membaca data dengan benar! Harap verifikasi.) Bahkan jika MTU seharusnya tidak mengizinkan itu, karena diatur ke 1500 pada NAS, pengaturan maksimum akan menjadi 9000 di sana (Synology juga menggunakan pengaturan 1500 dalam tes mereka).
4. Mencoba memaksa macOS untuk menggunakan SMB3 dengan menambahkan smb_neg=smb3_onlyke /etc/nsmb.conf tidak berfungsi atau setidaknya tidak mengarah ke transfer yang lebih cepat.
5. Menjalankan rsync --sockopts=TCP_NODELAYdengan berbagai kombinasi pengaturan ack tertunda TCP (0 hingga 3) tidak berpengaruh (Catatan: Saya menjalankan tcpdump dengan pengaturan ack default 3).

Saya telah membuat 4 kesedihan sebagai file .csv, 2 saat menyalin 512 MB (test-2.file) dan 2 saat menyalin 1024 MB (test.file). Anda dapat mengunduh ekspor Wireshark di sini (25,2 MB). Mereka zip untuk menghemat ruang dan dinamai cukup jelas.

Perbarui 3 - output smbutil

Output smbutil statshares -aseperti yang diminta oleh harrymc di komentar.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Catatan tentang ini: Saya yakin SIGNING_SUPPORTEDberada di truesini tidak berarti pengaturan di konfigurasi tidak berfungsi. Tapi hanya itu yang didukung oleh NAS. Saya telah memeriksa tiga kali lipat bahwa mengubah signing_requiredpengaturan pada konfigurasi saya memiliki efek pada kecepatan tulis (~ 20 MB / s saat disetel, ~ 60 MB / s saat mati).

Pembaruan 4 - Perang Samba: Harapan Baru

Rasanya agak memalukan, tetapi masalah utama di sini - lagi - tampaknya adalah pengukuran.

Ternyata rsync --progress -abiayanya sekitar 30 MB / s dari kecepatan menulis. Menulis dengan ddlangsung ke pangsa SMB dan menggunakan time cp /local/test.file /NAS/test.filelebih cepat sekitar 85-90 MB / s dan tampaknya cara tercepat untuk menyalin adalah macOS Finder di sekitar 100 MB / s (yang juga merupakan metode yang paling sulit untuk diukur, karena tidak ada indikator waktu atau kecepatan - siapa yang butuh itu, kan? o_O). Kami mengukurnya dengan pertama-tama menyalin file 1 GB dan kemudian file 10 GB, menggunakan stopwatch.

Apa yang telah kami coba sejak pembaruan terakhir dari pertanyaan ini.

1. Salin dari klien Mac ke klien Mac. Keduanya memiliki SSD (MacPro menulis dengan 250 MB / s untuk memiliki disc, MacBook Pro dengan 300 MB / s). Hasil: Sedikit 65 MB / s melalui ddtulisan dari MacBook Pro ke MacPro ( rsync25 MB / s). Melihat 25 MB / s adalah saat ketika kami mulai mempertanyakan rsync. Masih 65 MB / s sangat lambat. Jadi implementasi SMB pada macOS sepertinya ... well, dipertanyakan.
2. Mencoba pengaturan ack yang berbeda dengan dd dan cp - tidak berhasil.
3. Akhirnya kami menemukan cara untuk mendaftar semua opsi nsmb.conf yang tersedia. Ini sederhana man nsmb.conf. Perhatian versi online sudah usang!

Jadi kami mencoba beberapa pengaturan lagi, di antaranya:

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

Catatan: smb_neg=smb3_onlyadalah - seperti yang saya harapkan - bukan pengaturan yang valid. protocol_vers_map=4harus setara dengan yang valid.

Lagi pula, tidak ada pengaturan ini yang membuat perbedaan bagi kami.

Sekilas pertanyaan baru

1. Mengapa rsync merupakan cara yang mahal untuk menyalin satu (1!) File. Tidak banyak yang bisa disinkronkan / dibandingkan di sini, kan? Tcpdump juga tidak mengindikasikan kemungkinan overhead.

2. Mengapa dddan cplebih lambat daripada pencari macOS ketika mentransfer ke saham SMB? Sepertinya saat menyalin dengan Finder, ada sedikit pengakuan dalam komunikasi TCP. (Lagi: Pengaturan ack mis. Tidak delayed_ack=1ada bedanya bagi kami.)

3. Mengapa Windows tampaknya mengabaikan MTU, mengirimkan paket TCP yang lebih besar dan karenanya lebih sedikit, menghasilkan kinerja terbaik, dibandingkan dengan segala sesuatu yang mungkin dilakukan melalui macOS.

Ini adalah bentuk paket-paket dari macOS (terus-menerus 1514)

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

Dan ini berasal dari Windows (hingga 26334, ukuran bervariasi)

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

Anda dapat mengunduh .csv penuh di sini (25,2 MB), nama-nama file menjelaskan apa yang telah disalin (OS, metode transfer, dan ukuran file).

1. pertanyaan serupa tetapi memiliki jawaban yang menarik, mungkin Anda dapat memeriksa utas ini terutama di komentar 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Berikut kutipan "Peter van Hooft". Meskipun saya tidak yakin pengujian berdasarkan apa / yang dist linux. dan versi rsync juga. Namun: 1. dia memberi kami pemikiran untuk mencoba - bendera flag jika mungkin untuk meningkatkan kinerja. 2. dia menguji pada protokol NFS tetapi bertemu masalah kecepatan yang sama, karena itu, IT mungkin bukan protokol (SMB2 / 3, AFP, dll) alasannya.

Kami menggunakan rsync untuk menyalin data dari satu server file ke server file lain menggunakan NFS3 melalui tautan 10Gb. Kami menemukan bahwa menaikkan ukuran buffer (sebagai tes cepat) meningkatkan kinerja. Saat menggunakan --sparse ini meningkatkan kinerja dengan faktor lima puluh, dari 2MBps menjadi 100MBps.

2. Berikut ini adalah inspeksi menarik tentang kinerja rsync. https://lwn.net/Articles/400489/

LWN.net memiliki Kesimpulan bahwa masalah kinerja mungkin relevan dengan kernel bahkan artikel yang diposting pada 2010 dan kami tidak dapat diubah pada NAS atau MacOS. Namun, artikel ini memberi kami pemikiran bahwa masalah kernel dapat disebabkan oleh perhitungan checksum ( dugaan saya).

Satu hal yang jelas: Saya harus memutakhirkan kernel pada sistem Mythtv saya. Secara umum, kernel 2.6.34 dan 2.6.35-rc3 memberikan kinerja yang lebih baik daripada kernel 2.6.27 yang lama. Tapi, bermain-main atau tidak, rsync masih tidak bisa mengalahkan cp sederhana yang menyalin lebih dari 100MiB / s. Memang, rsync benar-benar membutuhkan banyak daya CPU untuk salinan lokal sederhana. Pada frekuensi tertinggi, cp hanya membutuhkan waktu CPU 0,34 + 20,95 detik, dibandingkan dengan rsync's 70 + 55 detik.

juga mengutip komentar memiliki ini:

Perhatikan bahwa rsync selalu memverifikasi bahwa setiap file yang ditransfer direkonstruksi dengan benar di sisi penerima dengan memeriksa checksum seluruh file yang dihasilkan saat file ditransfer

perbarui 1 : kesalahan saya, deskripsi ini untuk --checksum periksa di sini: [Memperbaiki deskripsi opsi --checksum.] PS, saya tidak punya cukup reputasi untuk mengirim lebih dari 2 tautan.

tetapi saya tidak dapat menemukan deskripsi yang sama dari halaman manual rsync, jadi saya menduga seseorang sedang berbicara tentang di bawah Bold:

Rsync menemukan file yang perlu ditransfer menggunakan algoritma "pemeriksaan cepat" (secara default) yang mencari file yang telah berubah ukurannya atau dalam waktu yang terakhir dimodifikasi. Setiap perubahan dalam atribut yang disimpan lainnya (seperti yang diminta oleh opsi) dilakukan pada file tujuan secara langsung ketika pemeriksaan cepat menunjukkan bahwa data file tidak perlu diperbarui.

Oleh karena itu, dibandingkan dengan cp / tar / cat, jika kita menggunakan rsync untuk menyalin banyak file kecil atau besar itu dapat menyebabkan masalah kinerja. TETAPI karena saya tidak dapat membaca kode sumber rsync karena itu saya tidak dapat mengkonfirmasi ini adalah alasan utamanya.

ide saya terus memeriksa:

1. Versi rsync apa yang awenro gunakan untuk pengujian? Bisakah Anda memperbarui ke versi terbaru?
2. mari kita lihat apa output ketika menggunakan --stats dan -v dengan --debug = FLAGS

bendera

--stats Ini memberitahu rsync untuk mencetak sekumpulan statistik verbose pada transfer file, memungkinkan Anda untuk mengetahui seberapa efektif algoritma rsync untuk data Anda.

--debug = BENDERA Opsi ini memungkinkan Anda memiliki kendali yang baik atas hasil debug yang ingin Anda lihat. Nama bendera individu dapat diikuti oleh nomor level, dengan 0 arti untuk membungkam output itu, 1 menjadi level output default, dan angka yang lebih tinggi meningkatkan output dari flag itu (bagi mereka yang mendukung level yang lebih tinggi). Gunakan --debug = bantuan untuk melihat semua nama bendera yang tersedia , apa yang mereka hasilkan, dan nama bendera apa yang ditambahkan untuk setiap peningkatan level verbose.

pada akhirnya, saya akan merekomendasikan membaca posting tambahan ini untuk mendapatkan lebih banyak pengetahuan.
"Cara mentransfer data dalam jumlah besar melalui jaringan" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh mengenkripsi koneksi seseorang tidak, jika saya ingat dengan benar. Jika hanya satu file maka satu sistem mungkin dapat membaca file itu dan yang lainnya tidak. Juga perhatikan bahwa untuk memiliki MTU di atas 1514 Anda perlu mengaktifkan paket "giants" / "Jumbo Frames" fakta bahwa paket perlu dikurangi lebih lanjut mungkin berimplikasi bahwa ada overhead untuk "mengemas kembali" paket tersebut. Hal kedua yang perlu diperhatikan adalah bahwa "raksasa" / "Jumbo Frames" perlu diaktifkan di kedua ujung DAN SETIAP ANTARA.

1514 adalah frame Ethernet normal. Frame 6k-9k disebut raksasa atau "Jumbo Frames" tergantung pada OS / aplikasi

Saya rata-rata 80MB / s antara nas saya (PC dengan VMs salah satu VM adalah NAS) dan stasiun saya (pc) dengan sftp (menggunakan sshfs) [raksasa tidak diaktifkan] dan perangkat di antaranya adalah microtik 2011 (pergi hanya tru switch chip)

Ingatlah bahwa MTU dinegosiasikan antara dua titik dan bahwa di sepanjang jalan Anda mungkin memiliki beberapa MTU pada kapasitas yang berbeda dan bahwa MTU akan menjadi yang terendah yang tersedia.

sunting: SMB tidak terlalu efisien untuk transfer file.