8

Samba gives me 24 MB/s read and 44 MB/s write, while ftp gives 97 and 112 MB/s under the same circumstances.

The documentation says that

Generally, you should find that Samba performs similarly to ftp at raw transfer speed.

In my case it clearly doesn't.

Where can I find tips on how to debug Samba performance?

Or alternatively tips for replacing Samba with something else? (I can't use ftp, unfortunately, as I need something that can be used with rsync/rsnapshot.)

More details:

  • Both computers are running Ubuntu 10.10 (using Samba because I have a Mac as well)
  • The Samba share is on a local home network, mounted as

    $ mount
    ...
    //server.local/share/ on /mnt/share type cifs (rw,mand)
    
  • Samba performance was tested by copying (cp) a single file of ~4GB to and from the share, using time for timing and calculating transfer speed by hand.

  • ftp performance are the numbers from the ftp client for get/put of the same file.
  • iperf gives network speed ~900 Mbits/s
  • bonnie++ gives disk speeds >200 MB/s on both sides for block reads as well as block writes
  • Tried changing the parameters suggested in the performance tuning HOWTO (read/write raw, read size, socket options), most of them made little to no difference. (The one that made a difference caused write speed to drop 50%.)
1

3 Answers 3

3

Actually FTP has quite an efficient data throughput rate once it gets going. The overhead that slows things down is with the getting a file downloading in the first place. That's not to say that there isn't a problem with Samba here. It should be performing nearly identically.

To be honest, I don't have much of a clue where you should start trying to fix this.

Ideally you'd be able to drop another computer in there with a reference install of Samba (eg Windows) and test that as both a client and server against the Ubuntu machines. Then you'd know which machine was the problem, if it was just one direction that was the problem and then you'd be able to report bugs based on this and/or find a workaround for the interim.

A while back I saw something about certain network hardware glitching under Samba. It was both switches and network adapters but I can't for the life of me find anything about it. It was probably such an edge case that it's not worth considering.

How about we sidestep Samba? FTP might not work but what about NFS? It probably has the highest transfer speeds out of the lot (in my experience) and it should handle rsync fine.

You could also look at FUSE-mounting the FTP server so rsync can bully it.

3
  • Thanks for tip and feedback - I had no idea that it's possible to cifs-mount FTP? I'll look into NFS as well. If the poor Samba performance is something non-trivial and not Ubuntu-related, perhaps it belongs on the Samba mailing list or some such rather than here? Jan 14, 2011 at 21:02
  • Yours is probably the best answer I'm going to get :) Thanks again. Jan 15, 2011 at 16:10
  • 1
    you can mount ftp resource: curlftpfs [user@]host:[dir] mountpoint [options]
    – jet
    Jan 24, 2011 at 16:30
1

What kind of performance do you get from running rsync over ssh? Maybe you could do your rsync with ssh and then also use samba for when you need to transfer stuff between your mac?

1
  • rsync over ssh gives 60 MB/s, about midway between Samba and FTP. But just saw a tip elsewhere that rsync in daemon mode (having one machine be rsync server) can on par with FTP, I'll try that next. Jan 21, 2011 at 8:05
1

you can try this in smb.conf

socket options = SO_KEEPALIVE SO_REUSEADDR \
   SO_BROADCAST TCP_NODELAY IPTOS_LOWDELAY \
   IPTOS_THROUGHPUT SO_SNDBUF=8192 SO_RCVBUF=8192

oplocks = yes

write raw = yes
read raw = yes
1
  • I've tried some of them. TCP_NODELAY: Tiny improvement. write raw and read raw: No discernable difference. SO_SNDBUF and SO_RCVBUF: Reduced write performance with 50%, didn't pursue further. I'll check out the rest when I get the chance. Jan 21, 2011 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .