SMB diklaim "lambat"

Jaringan perusahaan kami (yang saya percaya adalah domain windows yang berjalan di server 2008) sangat lambat. Contoh utama dari ini adalah menyalin file lebih dari SMB - daftar membutuhkan waktu beberapa menit, dan menyalin bahkan file berukuran sedang bahkan lebih lama. Ketika didekati mengenai masalah ini, manajer TI (yang, terlepas dari apa pun kelebihan lain yang mungkin ia miliki, adalah orang yang sangat keras kepala dan bukan orang yang sangat teknis) mengangkat tangannya, menjadi sangat defensif dan memberikan alasan alih-alih mendengarkan dan berusaha untuk cari tahu akar penyebab masalahnya.

Sekarang, mengakui bahwa unsur manusia dari masalah ini akan membutuhkan waktu dan upaya untuk menyelesaikannya, saya tidak tahu bagaimana cara secara teknis membantah alasannya. Dalam hal ini, ia mengklaim bahwa SMB adalah masalahnya, dan itu adalah protokol "lambat". Apakah ada bukti untuk pernyataan ini (saya hanya punya bukti kontra anekdotal)? Apa cara terbaik untuk membuat kemajuan dalam argumen ini?

SMB mungkin lebih lambat daripada beberapa protokol berbagi file lainnya, dan mungkin lebih cepat daripada yang lain. Tapi itu bukan bagian yang penting.

Alih-alih membuat pertanyaan / argumen, dapatkah Anda menemukan cara untuk beralih dari itu dan bertanya apakah SMB secepat (atau selambat!) Seperti yang seharusnya . Misalnya, dapatkah Anda mentransfer file menggunakan FTP antara server dan workstation yang mengalami kelambatan dan melihat peningkatan kinerja yang ditandai?

Vendor mungkin dapat mengarahkan Anda ke ulasan untuk perangkat keras, dengan Windows diinstal, yang berbicara tentang kinerja server file.

Dalam pengalaman saya, SMB lebih dari "cukup cepat" di jaringan saya. Kami menjalankan jaringan 10Gb di antara server dan kami sangat senang dengan kinerja server file menggunakan SMB dan kami telah mengukur lompatan kinerja yang baik pada perangkat keras yang sama tergantung pada apakah kami menggunakan NIC 1Gb ​​atau 10Gb. SMB bukan masalah bagi kami.

Saya pasti akan melihat hal-hal lain di jaringan Anda - apakah infrastrukturnya sudah ketinggalan zaman, apakah sudah dikonfigurasi secara optimal (mis. Kartu jaringan server semuanya dikonfigurasi dengan benar untuk driver terbaru, bekerja dengan baik pada kecepatan terbaik), adalah hal-hal seperti DNS dan sebagainya- pada semua yang dikonfigurasikan dengan benar, apakah ada banyak "sampah" lalu lintas di jaringan yang menyebabkan pelambatan, apakah antivirus dikonfigurasi dengan cara yang terlalu paranoid (Saya telah melihat ini menyebabkan beberapa perlambatan yang mengejutkan ).

Ada banyak yang dapat menyebabkan kinerja server file yang buruk dan sangat sedikit itu adalah pilihan protokol.

Meskipun ada protokol yang lebih cepat dari SMB, itu tidak berarti lambat.

Namun mungkin sedikit lebih rentan terhadap pengaruh luar daripada protokol lain, ini adalah server jenuh, segmen jenuh dll.

Jika saya seorang pemain judi, saya curiga jaringan Anda dapat melakukan desain ulang atau investasi karena banyak jaringan kantor reguler perusahaan belum ditingkatkan untuk memperhitungkan peningkatan besar dalam internet dan lalu lintas intranet yang terlihat selama beberapa tahun terakhir. Juga ada kemungkinan yang masuk akal bahwa server perlu mengganti atau mengerjakan ulang untuk mendapatkan yang terbaik dari mereka.

Either way saya tidak akan terlalu menekankan pada SMB menjadi penyebab langsung, itu lebih dari kemungkinan hanya jatuh-orang untuk jaringan yang buruk / lama dan kit server.

Itu memang memiliki lebih banyak overhead (untuk transfer) daripada hal-hal seperti NFS atau FTP. Daftar file direktori besar dapat memakan waktu cukup lama - beberapa di antaranya disebabkan oleh SMB, beberapa karena NTFS, beberapa karena hal-hal bodoh yang dapat dilakukan oleh berbagai versi Explorer, dan perangkat lunak yang diinstal, dari sisi klien. Hal-hal tertentu seperti basis data berbasis file (Access, file PST) tidak boleh dibuka di tautan yang lambat (WAN) karena tidak menangani latensi dengan baik.

Karena itu, operasi yang Anda uraikan seharusnya tidak memakan waktu lama. Mungkin fileserver (s?) Di bawah daya. Mungkin perusahaan memiliki beberapa perangkat lunak sebagai bagian dari pemasangan standar yang memperlambat segalanya. Mungkin ada pemindai virus yang salah konfigurasi. Mungkin ada virus. Mungkin ada tautan WAN yang tidak Anda ketahui antara Anda dan server.

1. Apakah daftar file lebih cepat jika Anda melakukannya dari baris perintah daripada Explorer?
2. Bagaimana dengan menyalin?
3. Ping server yang dimaksud dari desktop Anda - apa latensinya?
4. Lakukan traceroute - berapa banyak hop di antara Anda dan server?

Sayangnya Nate, kami tidak bisa berurusan langsung dengan PHB. Baris pertahanan pertama Anda di sini adalah metrik aktual, seperti, lakukan perbandingan antara transfer SMB dan NFS, misalnya.

Setelah Anda memiliki angka atau statistik aktual untuk mendukung argumen Anda, Anda tidak perlu terlalu banyak berurusan dengan elemen manusia. Statistik mengatakan, "Di sinilah masalahnya, dan inilah buktinya." Itu argumen Anda.

Bisakah Anda mempersempitnya? Apakah transfer server ke server pada subnet yang sama memiliki hasil yang lebih baik? Bagaimana dengan transfer dari satu klien ke klien lain ( \\client\c$→ \\client\d$)?

Anda mungkin menemukan sesuatu yang sederhana seperti duplex mismatch.

Saya tahu ini sudah tua, tetapi faktor yang sangat penting untuk dipertimbangkan adalah disk I / O. Jika kinerja penulisan disk sangat lambat karena perangkat lunak / motherboard RAID sebagai lawan dari kartu RAID berbasis perangkat keras dengan memori khusus.

Beban jaringan adalah faktor, tetapi hal terbaik untuk dilakukan sebagai sysadmin adalah melihat Resource Monitor dan periksa dari mana kemacetan mungkin berasal - memeriksa tab Ikhtisar untuk menampilkan CPU, Jaringan, Disk I / O, Memori, dll. Keseluruhan. Dari tempat ini, Anda dapat melihat apakah ada proses pelakunya atau serangkaian proses yang menggerogoti Disk I / O, atau kebocoran memori (SQLServer.exe - contoh SBSMonitoring), dll. Jika ada proses jaringan yang menggunakan banyak bandwidth, periksa proses itu dan periksa berapa banyak dan apa host yang terkait dengan proses itu. Bisa jadi banyak upaya hack untuk RDP di pada 3389. Saya telah melihat bahwa sebelumnya sebagai kasus dan solusi kami adalah untuk menghapus akses RDP langsung dan mengalihkan pengguna jarak jauh ke VPN di.

Semoga ini membantu!