↓ Lewati ke konten utama
  1. Posts/

Transfer File SMB Lambat? Ini Cara Memperbaikinya dengan Benar

Noor Khafidzin
Penulis
Noor Khafidzin
Seorang homelab enthusiast yang terobsesi pada efisiensi sistem dan seni pemecahan masalah (troubleshooting).
Daftar isi

Pendahuluan
#

Anda mulai menyalin disk VM berukuran 300 GB ke file share Windows. File Explorer menunjukkan 110 MB/s di beberapa detik pertama, lalu angkanya jatuh ke 8 MB/s dan bertahan di sana. Atau Anda menyalin folder berisi 40.000 file kecil dan melihat prosesnya merangkak di 900 KB/s sepanjang sore.

Kedua masalah ini punya sebab yang jelas. SMB, protokol di balik file sharing Windows, peka terhadap cara penyalinan, perilaku storage, dan beban CPU. Begitu Anda tahu mana dari ketiganya yang jadi penghambat, perbaikannya biasanya cuma satu flag atau satu setelan.

Panduan ini menyusun pemeriksaan sesuai urutan yang paling menghemat waktu. Dasarnya panduan troubleshooting resmi Microsoft, dan bagian yang paling berpengaruh di lapangan saya taruh di depan.

Versi 30 detik: berhenti memakai File Explorer untuk pekerjaan besar, pakai robocopy dengan flag yang tepat, aktifkan kompresi SMB kalau datanya cocok, dan cek throughput storage sebelum menyalahkan jaringan.

Gejala → langkah pertama
#

Yang Anda lihat Mulai dari sini
Satu file besar (ISO, VHDX, backup) lambat robocopy /J untuk I/O tanpa buffer
Ribuan file kecil merangkak robocopy /MT plus file log
Kecepatan tinggi di awal, lalu jatuh Cache storage penuh, jadi cek kecepatan tulis berkelanjutan
Cepat di LAN, lambat lewat WAN/VPN Biaya SMB signing dan enkripsi, juga perilaku TCP
Hanya file Office yang lambat dibuka SMB leasing
Di hardware 10 Gbps cuma dapat 1 Gbps SMB Multichannel, storage, atau batas CPU

1. Alat copy lebih menentukan dari yang Anda kira
#

File Explorer melakukan copy single-threaded dengan buffered I/O, dan untuk beberapa dokumen cara ini cukup. Untuk transfer besar, alat ini salah pilih.

robocopy dibuat persis untuk pekerjaan ini: multi-threaded, bisa melewati buffer, dan bisa menulis progres ke file log ketimbang menggambar ulang konsol setiap kali satu file selesai.

Untuk satu file besar, pakai I/O tanpa buffer dengan /J:

robocopy "D:\ISOs" "\\fileserver\share\ISOs" *.iso /J /R:1 /W:1 /LOG:"C:\logs\robocopy-iso.log"

Untuk banyak file kecil, pakai multithreading dengan /MT:

robocopy "D:\Projects" "\\fileserver\share\Projects" /E /MT:16 /LOG:"C:\logs\robocopy-small.log"

Catatan untuk flag di atas:

  • /J berarti I/O tanpa buffer. Efektif untuk file di atas sekitar 1 GB.
  • /MT:16 menyalin 16 file sekaligus. Default-nya 8, maksimal 128.
  • /LOG penting. Menulis progres ke konsol itu lambat, dan pada pekerjaan file kecil bagian waktunya bisa terasa.
  • Jangan langsung lompat ke /MT:128. Thread lebih banyak tidak otomatis lebih cepat. Dua thread per core CPU adalah titik awal yang aman, lalu ukur.

2. File kecil adalah masalah yang berbeda
#

Ini bagian yang sering dilewati panduan lain. Menyalin 50.000 file berukuran di bawah 1 MB lebih banyak menghabiskan waktu di pembuatan file daripada di pemindahan data.

Untuk setiap file, SMB mengirim perintah create, file system bekerja, data ditulis, lalu file ditutup. Rangkaian itu melewati jaringan, stack SMB, file system, dan sering juga filter driver antivirus. Dengan alat single-threaded, link jaringan menganggur sementara setiap file dibuat.

Itu sebabnya throughput bisa turun di bawah 1 MB/s meski jaringan gigabit Anda sehat.

Multithreading memperbaikinya dengan menumpuk waktu tunggu: saat satu atau dua file sedang dibuat, data file lain sudah dalam perjalanan. Karena itu /MT dipakai.

Kalau pekerjaan masih lambat meski sudah pakai /MT, ada beberapa jalan keluar. Cara paling sederhana adalah mengarsipkan folder lebih dulu, menyalin satu arsip itu, lalu mengekstraknya secara lokal di tujuan. Ekstrak langsung di atas SMB hanya akan mengulang masalah file kecil dari awal.

Kalau tujuannya Azure Storage, AzCopy sudah membawa concurrency dan tuning khusus cloud. Alat copy multi-threaded lain juga boleh dipakai, asalkan Anda mengukur kecepatan sebelum dan sesudahnya.

3. Kompresi SMB: aktifkan kalau datanya cocok
#

Kompresi SMB memampatkan data saat transfer berlangsung. Yang dibayar sedikit CPU; yang dihemat bandwidth dan waktu. Di link 1 Gbps atau Wi-Fi, biaya CPU sekecil itu biasanya sepadan dengan waktu yang dihemat.

Paling terasa pada file yang banyak ruang kosong atau datanya berulang. Disk mesin virtual seperti .vhd, .vhdx, .vmdk, dan .ovf termasuk yang paling diuntungkan, begitu pula image .iso dan crash dump .dmp.

Data yang sudah termampat nyaris tidak mendapat apa pun. Arsip .zip, .7z, .rar, video .mp4 atau .mkv, dan audio .mp3 atau .flac sudah memadat sendiri, jadi hasil kompresinya kecil.

Kompresi SMB tersedia mulai Windows 11 dan Windows Server 2022. Anda bisa mengaktifkannya per share:

Set-SmbShare -Name "Backups" -CompressData $true

Atau memintanya untuk mapped drive:

New-SmbMapping -LocalPath "Z:" -RemotePath "\\fileserver\Backups" -CompressNetworkTraffic $true

Bisa juga untuk satu pekerjaan robocopy saja:

robocopy "C:\VMs" "\\fileserver\Backups\VMs" *.vhdx /COMPRESS

Satu catatan: kompresi SMB tidak berjalan di atas SMB Direct lewat RDMA. Kalau Anda memakai hardware RDMA, kompresi memang dilewati secara desain.

4. Storage biasanya jadi plafon sebenarnya
#

Menyalahkan jaringan itu mudah, padahal storage di bawah share sering kehabisan kecepatan tulis berkelanjutan lebih dulu.

Angka kasar Microsoft untuk SMB di dunia nyata, dengan asumsi tidak ada masalah CPU, memori, atau jaringan:

Bandwidth jaringan Throughput storage berkelanjutan yang dibutuhkan
1 Gbps ~110 MB/s
10 Gbps ~1,1 GB/s
100 Gbps ~11 GB/s

Angka di tabel itu berlaku untuk copy panjang. Angka puncak yang diiklankan produsen drive biasanya cuma bertahan beberapa detik, dan selisihnya bisa beberapa kali lipat.

Kalau link 10 Gbps Anda mentok di 300 MB/s, link-nya mungkin baik-baik saja. Yang bermasalah bisa jadi array di belakangnya.

Untuk throughput sangat tinggi tanpa membebani CPU, lihat SMB Direct (SMB over RDMA). Dengan cara ini keterlibatan CPU jauh lebih kecil, dan transfer besar cenderung lebih stabil.

5. “Awalnya cepat, lalu melambat”
#

Ini cache cliff yang klasik.

Bagian awal copy diserap cache storage dan memori sistem. Saat buffer itu penuh, Windows beralih ke write-through dan kecepatannya turun ke level yang benar-benar bisa dipertahankan media di bawahnya.

Untuk memastikannya, buka RAMMap dari Sysinternals dan pantau nilai Mapped File. Kalau angkanya berhenti naik, buffer memori sudah habis. RAMMap tidak refresh sendiri, jadi tekan F5.

Setelah itu bandingkan counter storage dengan throughput jaringan. Kalau performa storage turun tepat saat kecepatan copy turun, jawabannya ada di situ.

Di Windows Server 2016 ke atas ada pola lain: performa menurun kira-kira setiap 5 GB. Itu mengarah ke ambang dirty page file remote, yang bisa diatur di setelan cache and memory management.

6. Periksa jaringan, tapi periksa hal yang benar
#

Masalah jaringan itu nyata, hanya saja solusinya lebih sempit daripada yang beredar di forum.

  • Cari packet loss. TCP bereaksi terhadap loss dengan menurunkan lajunya sendiri. Link yang terlihat jalan tetap bisa membuang frame tanpa error yang tampak.

  • Jangan matikan network offload. RSS, LSO, RSC, dan checksum offload TCP/UDP ada untuk menaikkan throughput dan menurunkan beban CPU. Mematikannya biasanya justru memperburuk keadaan.

  • Cek SMB Multichannel. Di SMB3, beberapa jalur jaringan bisa dipakai bersamaan. Pastikan aktif:

    Get-SmbMultichannelConnection
  • Cek batas di sisi client. Pastikan MTU besar aktif dan bandwidth throttling mati:

    Set-SmbClientConfiguration -EnableBandwidthThrottling 0 -EnableLargeMtu 1

Kalau client kehabisan CPU saat transfer cepat, batasnya ada di stack SMB.

7. SMB signing dan enkripsi punya biaya
#

SMB signing dan SMB encryption diketahui menurunkan kecepatan transfer. Seberapa besar tergantung hardware: jumlah core, kecepatan core, dan sisa waktu CPU setelah semua pekerjaan lain.

Mulai Windows 11 versi 24H2 dan Windows Server 2025, SMB signing wajib aktif secara default. Microsoft secara eksplisit menyarankan untuk tidak mematikannya, karena signing melindungi dari spoofing, tampering, dan serangan relay.

Jangan matikan SMB signing hanya demi mengejar throughput. Tambah kapasitas CPU sebagai gantinya. Tidak ada angka benchmark yang sepadan dengan kontrol keamanan, apalagi di file server yang menyimpan data orang lain.

8. Antivirus bisa jadi pajak tersembunyi
#

Endpoint protection memindai trafik jaringan dan operasi file system. Untuk satu file besar, biaya itu dibayar sekali. Untuk 30.000 file kecil, biaya yang sama dibayar 30.000 kali.

Untuk mengukurnya, uji copy sementara dengan file scanning dimatikan dan filter driver dilepas. Kalau kecepatan melonjak, di situ letak sebagian besar masalahnya. Setelah itu bicarakan dengan tim keamanan soal exclusion untuk peran file server, jangan langsung mematikan antivirus di seluruh mesin.

9. File Office lambat dibuka? Itu leasing
#

Kalau copy file biasa baik-baik saja tetapi workbook Excel merangkak saat dibuka dari share, terutama lewat WAN, penyebabnya biasanya SMB leasing. Bandwidth hampir tidak berpengaruh di kasus ini.

Uji dengan mematikan leasing di server:

Set-SmbServerConfiguration -EnableLeasing $false

Di Windows Server 2019 ke atas, Anda bisa mengaturnya per share:

Set-SmbShare -Name "Finance" -LeasingMode Shared
Pakai dengan hati-hati. Leasing adalah bagian inti SMB dan yang memungkinkan read cache, write cache, serta handle cache. Mematikannya bisa menyembuhkan satu aplikasi lambat tapi memperlambat yang lain. Coba Shared dulu. Simpan None sebagai pilihan terakhir. Perubahan berlaku untuk koneksi SMB baru, tanpa perlu reboot.

Kalau Anda menguasai sisi tujuan, file bisa direplikasi ke file server lokal supaya Office membukanya lewat LAN.

10. Saat lambat itu memang wajar
#

Sebagian workload memang lambat sejak awal, dan itu wajar.

Backup, database, dan deployment Scale-Out File Server (SOFS) sering membutuhkan write-through, yang melewati semua cache dan langsung menulis ke media storage. Kalau performa write-through storage-nya buruk, SMB akan tetap lambat berapa pun tuning yang Anda lakukan.

Dalam kasus seperti itu, yang perlu diperbaiki adalah storage.

Kesimpulan
#

Kerjakan dengan urutan ini:

  1. Alat copy: robocopy sebagai ganti File Explorer.
  2. Pola file: /J untuk file besar, /MT untuk banyak file kecil.
  3. Kompresi: aktifkan kalau datanya bisa dimampatkan.
  4. Storage: pastikan throughput berkelanjutan.
  5. Jaringan: cek loss, multichannel, MTU, dan offload.
  6. Perangkat keamanan: ukur pajak antivirus.

Sebagian besar kasus “SMB lambat” selesai di dua langkah pertama. Sisanya untuk kasus yang belum selesai di dua langkah itu.

Kalau punya kasus yang membandel, tulis perintah robocopy, ukuran file, kecepatan link, dan tipe storage Anda di komentar. Kombinasi itu biasanya langsung menunjukkan sumber bottleneck-nya.

Referensi
#

Terkait


Muat Komentar