Mengapa saya melihat throughput transfer SMB yang rendah?


10

Ok, ada sedikit lebih banyak cerita daripada judulnya.

Latar Belakang dan Lingkungan : Saya menyalin beberapa TB dari server Ubuntu yang lebih lama ke server Windows 2012 yang lebih baru melalui SMB. (Secara teknis, ini adalah perangkat keras komoditas, tetapi mereka server di sekitar sini.) Semua orang menggunakan LAN gigabit, dan kotak Ubuntu yang lebih lama memiliki antarmuka terikat. Saya percaya server Ubuntu memiliki dua kartu ethernet PCI-e 1x Rosewill dan server Windows memiliki satu kartu ethernet PCI Intel yang cukup bagus.

Komputer tujuan (server Windows) menjalankan Storage Pool dengan paritas lebih dari drive 4x 2TB. Ini menjalankan ReFS baru Microsoft. Komputer sumber (server Ubuntu) menjalankan mirror RAID perangkat lunak. Ini berjalan dengan baik EXT4 ol.

Dua server berjalan melalui switch gigabit tunggal. Saya telah bereksperimen dengan memutus ikatan pada komputer sumber (Ubuntu) tanpa perbaikan apa pun.

Masalah : Saya tidak kesulitan mentransfer dengan kecepatan yang wajar dari komputer lain ke server Windows. Komputer lain dapat menampung 50-80MB / s tanpa banyak kesulitan, tetapi mentransfer dari server Ubuntu paling atas tidak lebih dari 20MB / s. 4 + TB pada 20MB / s membutuhkan waktu lama (sekitar 2,3 hari), dan saya bertanya-tanya apa yang bisa saya lakukan untuk mencari tahu di mana hambatannya.

Gejala : CPU pada kedua komputer sangat minim, dan tentu saja tidak terlalu sibuk. Hard drive pada kedua komputer aktif tetapi tidak kebanjiran, dan CPU IOwait hampir 0% pada setidaknya server Ubuntu.

Saya melakukan jejak Wireshark selama 35 detik (mungkin cukup lama untuk memastikan semua ACK untuk paket baru) dan memperhatikan bahwa ada beberapa hal yang tidak saya harapkan. (1) Tidak ada checksum untuk ACK (dan BEBERAPA paket SMB) dari Windows ke Ubuntu. Namun, Wireshark mengklaim bahwa ini mungkin disebabkan "IP checksum offload." Ok, saya punya kartu yang cukup bagus di sana. Saya kira ada kemungkinan kartu jaringan dapat melakukan perhitungan checksum. Baik. Pindah ... (2) "TCP segmen ACKed tak terlihat." Yang ini saya punya masalah. Nomor ACK berada dalam kisaran yang dapat diterima dari apa yang dapat saya katakan, dan sering ada blok besar dari pesan-pesan ini. Mungkin Wireshark terlalu lambat?

Rangkuman : Kecepatan transfer menyebalkan (20MB / dtk lebih dari gigabit ethernet) dan saya tidak tahu mengapa. Wireshark mengklaim Windows adalah ACKing hal-hal yang tidak pernah dikirim oleh Ubuntu.

Guesses : Tebakan awal saya adalah bahwa kartu Rosewill yang lebih murah semakin dibanjiri. Dugaan kedua saya adalah bahwa hal-hal seperti RAID perangkat lunak di satu sisi atau yang lain semakin dibanjiri dengan hal-hal yang harus dilakukan.


2
Berapa kecepatan yang Anda dapatkan menyalin dari server Ubuntu ke salah satu desktop (bukan Server 2012)? Mungkin WinXP atau Win7? Saya punya masalah besar dengan penandatanganan paket dan enkripsi dengan SMB dengan Server 2008 dan lebih tinggi.
Dom

Pembaruan: Saya akhirnya harus reboot (terima kasih atas kepanikan kernel). Sayangnya sistem sekarang memiliki kepanikan kernel di setiap boot. Saya mengeluarkan Knoppix saya yang terpercaya dan memasang drive, dan semuanya sekarang baik-baik saja dan keren. Sekarang saya menyalin SSH dan saya masih tidak tahu di mana hambatannya. sshdmemakan hingga 60% dari satu prosesor di sisi Knoppix. Bagaimanapun, transfer saya hampir selesai. @ Tom: Sekarang Anda menyebutkannya, saya tidak ingat meletakkan semua data di sana lebih cepat dari 30MBps di tempat pertama.
Andy

2
@LorenzoVonMatterhorn, harap hindari menggunakan penyingkat URL.
Cristian Ciupitu

Apakah Anda yakin ini bukan masalah dengan disk Anda?
MariusMatutiae

2
Windows mengimplementasikan versi jauh lebih cepat dari protokol SMB (SMB 2) selama 4-5 tahun terakhir yang jauh lebih cerewet dan lebih efisien pada kabel. Saya tidak tahu kapan perubahan itu bergulir ke Samba, tetapi sepertinya Ubuntu yang lebih lama memiliki Samba yang lebih lama dan mungkin Knoppix memiliki versi yang lebih baru.
uSlackr

Jawaban:


1

Kesenjangan kinerja Anda cocok dengan pengalaman umum ketika Samba (tidak yakin apakah ini masih default; sudah lama) dikonfigurasikan dengan default buffer buffer read and write socket 1024 bytes.

Saya sering melihat ini dengan mesin Linux dan Mac. Semoga tidak demikian.

Ada argumen opsi soket dalam file konfigurasi samba di mana Anda dapat mengatur ukuran buffer soket baca dan tulis. Sarankan Anda mengatur keduanya ke 8192 byte (8 KiB). 4 atau 8 KB sering serupa, tetapi saya belum mengujinya pada tautan gigabit.

Juga, jangan berharap koneksi TCP tunggal mendapat manfaat dari tautan berikat, lalu lintas akan hampir selalu melalui salah satu tautan; jika tidak, Anda akan berakhir dengan banyak paket rusak yang harus ditangani; jadi hanya mengharapkan manfaat load-balancing ketika melayani banyak klien. Bahkan kemudian, Anda harus mencari mode ikatan yang berbeda, dan tahu bahwa setidaknya untuk ikatan "mode 4" (IEEE 802.3ad), pada dasarnya ada dua mode hash pengiriman, yang menentukan antarmuka budak mana yang akan dikirim. Ada hashing layer-2 (default) dan hashing layer-3. Jika mengirim sebagian besar data Anda melalui gateway, hash layer-2 tidak akan terdistribusi dengan baik, karena alamat MAC gateway akan sama. Pertimbangkan untuk menggunakan layer-3 sebagai gantinya.


0

Saya pernah punya dua kartu Ethernet dalam satu komputer Ubuntu dan untuk beberapa alasan itu tidak berfungsi dengan baik - mereka berdua bersaing untuk paket yang sama sepertinya, jadi kadang-kadang saya akan mendapatkan balasan kadang-kadang saya tidak akan, tergantung jika kartu jaringan lain meraih yang dikemas. Itu aneh. Saya pasti sudah salah mengonfigurasi, tapi saya akan mengira itu hanya berfungsi. Kartu-kartu itu tentu saja memiliki alamat IP yang unik.

Bagaimanapun, akan mudah bagi Anda untuk mencobanya hanya dengan SATU kartu Ethernet di mesin yang terhubung ke jaringan hanya untuk mengesampingkan itu.

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.