Is your Samba slow?
Samba file sharing is great, but performance under Samba’s default configuration is fairly poor.
Here are a few options that I add to my smb.conf to get the speed that I need:
[global] # FORCE THE DISK SYSTEM TO ALLOCATE REAL STORAGE BLOCKS WHEN # A FILE IS CREATED OR EXTENDED TO BE A GIVEN SIZE. # THIS IS ONLY A GOOD OPTION FOR FILE SYSTEMS THAT SUPPORT # UNWRITTEN EXTENTS LIKE XFS, EXT4, BTRFS, OCS2. # IF YOU USE A FILE SYSTEM THAT DOES NOT SUPPORT UNWRITTEN # EXTENTS, SET "strict allocate = no". # NOTE: MAY WASTE DRIVE SPACE EVEN ON SUPPORTED FILE SYSTEMS # SEE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532 strict allocate = Yes # THIS IS TO COUNTERACT SPACE WASTAGE THAT CAN BE # CAUSED BY THE PREVIOUS OPTION # SEE: https://lists.samba.org/archive/samba-technical/2014-July/101304.html allocation roundup size = 4096 # ALLOW READS OF 65535 BYTES IN ONE PACKET. # THIS TYPICALLY PROVIDES A MAJOR PERFORMANCE BENEFIT. read raw = Yes # SERVER SIGNING SLOWS THINGS DOWN WHEN ENABLED. # THIS WAS DISABLED BY DEFAULT PRIOR TO SAMBA 4. # Thanks to Joe in the comments section! server signing = No # SUPPORT RAW WRITE SMBs WHEN TRANSFERRING DATA FROM CLIENTS. write raw = Yes # WHEN "strict locking = no", THE SERVER PERFORMS FILE LOCK # CHECKS ONLY WHEN THE CLIENT EXPLICITLY ASKS FOR THEM. # WELL-BEHAVED CLIENTS ALWAYS ASK FOR LOCK CHECKS WHEN IT IS # IMPORTANT, SO IN THE VAST MAJORITY OF CASES, # "strict locking = auto" OR "strict locking = no" IS ACCEPTABLE. strict locking = No # TCP_NODELAY: # SEND AS MANY PACKETS AS NECESSARY TO KEEP DELAY LOW # IPTOS_LOWDELAY: # [Linux IPv4 Tweak] MINIMIZE DELAYS FOR INTERACTIVE TRAFFIC # SO_RCVBUF: # ENLARGE SYSTEM SOCKET RECEIVE BUFFER # SO_SNDBUF: # ENLARGE SYSTEM SOCKET SEND BUFFER socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 # SMBWriteX CALLS GREATER THAN "min receivefile size" WILL BE # PASSED DIRECTLY TO KERNEL recvfile/splice SYSTEM CALL. # TO ENABLE POSIX LARGE WRITE SUPPORT (SMB/CIFS WRITES UP TO 16MB), # THIS OPTION MUST BE NONZERO. # THIS OPTION WILL HAVE NO EFFECT IF SET ON A SMB SIGNED CONNECTION. # MAX VALUE = 128k min receivefile size = 16384 # USE THE MORE EFFICIENT sendfile() SYSTEM CALL FOR EXCLUSIVELY # OPLOCKED FILES. # NOTE: ONLY FOR CLIENTS HIGHER THAN WINDOWS 98/Me use sendfile = Yes # READ FROM FILE ASYNCHRONOUSLY WHEN SIZE OF REQUEST IS BIGGER # THAN THIS VALUE. # NOTE: SAMBA MUST BE BUILT WITH ASYNCHRONOUS I/O SUPPORT aio read size = 16384 # WRITE TO FILE ASYNCHRONOUSLY WHEN SIZE OF REQUEST IS BIGGER # THAN THIS VALUE # NOTE: SAMBA MUST BE BUILT WITH ASYNCHRONOUS I/O SUPPORT aio write size = 16384
A few other references:
Not sure if all of the "socket options" are applicable to FreeBSD. Also, "strict allocate = Yes" makes a pretty big difference.
I did this under Linux. As for what low-level twiddling will get it up-to-par on FreeBSD (if that is even possible), I'd love to find out.
Under the [global] section. Just updated the post.
Thanks!
I was having slowness issues. I setup samba as a Primary Domain Controller. I had nice gigabit hardware: Intel nics, Netgear 24port gigabit switch gs724t. A Windows to Windows file transfer would saturate my gigabit connection at over 100MB/s (that's gigabits to megabytes!). However any transfers from Windows to or from Samba would not go over 60MB/s. None of the options above worked. Until I ran "top" on my Linux box and noticed that smbd was consuming 100% of the processor's time. I found somewhere else on the internet that disabling
server signingfixed the issue.Storage speeds should not be an issue if you have 7200 RPM drives with SATA-2 or higher. I have a Western Digital blue 500GB that can write speeds at 150MB/s (large files of course) with ease. A gigabit connection isn't going to go over too much more than 110MB/s.
So, in review check "top" during a file transfer and see if Samba (smbd) is going gang busters with your CPU. Although some issues will be fixed with the above options others will not. I'm only posting this because it took me several days to figure out my issue and maybe it'll help someone else!
Joe,
Which version of Samba are you running?
I'm on 4.2.14-Debian, with a
server signingvalue ofdefault.You can use
testparm -vsto list all current settings.P.S.> Thanks for the heads-up!
Hoenstly iam done with samba
For Years i struggle with performance issues, specially on virtulized setups (kvm with virtio driver) shure samba 4 has some really nice features and a real domain. thats all fine but no matter waht i try i never get even close to the performance i should have.
whiel network speedtests bring up almost the full gbit, samba is at best at 50-60mb/sec on large files. options above do help a bit but its far from a stable connect (jumps arounds 5-9 mb up and down) and never gets over 65mb/sec compared on the same physical host with an identical machine i runa 2012r2 with dedupe on the same spec (2cpus 2gig ram) one smb connect and get almsot rock solid 100mb/sec so something is off with samba.
what i noticed is i can improve a bit by nicing the smbd process but that makes things not really better, i mean 30% cpu usage with signing off is a bit much now iam going to switch voer to windows for smb for good.
data deduplication is a big factor there too (cant switch to zfs right now on linux) and the windows version does actually very good job on deduping on a block level.
on one hadn iam really sad about this, and doesnt make my life easier on the other samba isnt production ready yet, (after over a decade of trying) and probably never will. :(