1

I have just set up a new Samba 3.3 server on a virtualized CentOS 5.4 machine and have found that it is having performance issues under a very particular set of circumstances. My boss has a Macbook Pro running Mac OSX 10.6. When he tries to...say...transfer a 30 megabyte file onto the server, it is excruciatingly slow (15+ seconds).

Here is a couple of other interesting data points, though:

  • Transferring the same file off the server only takes a few seconds. The extreme slowness is only on write.
  • Transferring the same file onto an old samba server that we've already got set up running Fedora Core 5 and Samba 3.0 is almost instantaneous. Needless to say, we're trying to upgrade, or else we would continue to use it.
  • Transferring the same file onto the new server using SFTP takes 1-2 seconds.
  • When I try to transfer the same sample file onto the new server using my personal OSX 10.5 machine, it takes around 5-6 seconds no matter what protocol I use (Samba, SCP, SFTP). So it's slower than my bosses machine on the other protocols, but faster when using Samba.

I have already tried some of the speedup tricks listed in Google such as socket options = TCP_NODELAY, read raw and write raw, but none of them appear to have any effect on the resulting speeds. The firewalls are all configured correctly, with the virtual host passing along all bridged traffic to the appropriate virtual server and "Samba" is allowed through on the virtual server itself. I also looked through the old server's configuration file and nothing jumped out at me as being a "aha, this is why it's so fast."

Any other ideas?

EDIT: New information. I found out that my computer was using WiFi instead of ethernet. When I switched to ethernet, my performance on the server became identical to my bosses in every aspect (SFTP fast, Samba write super-slow, etc.).

AlexMax
  • 543
  • 1
  • 5
  • 15

3 Answers3

1

Set unix extensions = no

We additionally add

strict locking = no
blocking locks = no
kernel oplocks = no
posix locking = no

for our environment. Make sure you know what you're doing before changing the defaults. As always, man smb.conf and make use of the lists.

Join here:
https://lists.samba.org/mailman/

Search here:
http://marc.info/?l=samba
http://marc.info/?l=samba-technical

beans
  • 1,580
  • 13
  • 16
1

Is it possible the ethernet switch you're connecting to is mis-negotiating to a half-duplex connection with the Macs? Your description (high speed one direction, low the other, gets worse if you try to send data really fast) sounds like what I've seen when one end (the switch in your case) is in half-duplex mode and the other (the Mac) is trying to use full-duplex mode.

You can check the mode on the Mac with the ifconfig command (look for a line that says something like "media: autoselect (1000baseT ) status: active"; how you check (/whether you can check) on the switch depends on its management interface (if any). You might also be able to diagnose this using something like netstat -p tcp -s -- if this is the problem, you'll probably see lots of retransmits.

Note: if the server and Macs are on different switches, it's also possible there's a problem with the connection between switches.

Gordon Davisson
  • 11,216
  • 4
  • 28
  • 33
  • Good idea, but no cigar. My ifconfig output displays `media: autoselect (1000baseT ) status: active`. Also, if my connection was half-duplex, wouldn't this also cause an issue with SFTP as well? I _did_ do a before and after with `netstat` and found that of 22391 packets sent 647 of them were retransmits, but I don't really know if that's an acceptable number or not. – AlexMax Apr 01 '11 at 12:59
  • @AlexMax: that doesn't rule out a duplex mismatch -- you need to check the switch as well and make sure it has the Mac's port in full-duplex mode as well. If it's a dumb switch (i.e. no management interface to check), you may have to resort to things like manually switching the Mac into half-duplex mode and see if it gets better (the control for this is in System Preferences -> Network pane -> Ethernet service -> Advanced button -> Ethernet tab -> Manual mode, 1000BaseT, half-duplex). If there are several switches involved, you may also have to check the inter-switch links. – Gordon Davisson Apr 01 '11 at 20:03
  • @AlexMax: as for why SFTP doesn't seem to be affected, it may be (rather ironically) that it's because SFTP doesn't send data as fast. With a duplex mismatch, everything works fine until you try to shove data through the pipe too fast, at which point half-collisions start happening and things get very confused; SFTP may just not be sending data fast enough to cause a jam. – Gordon Davisson Apr 01 '11 at 20:08
  • @Gordon You might be on to something here. Changing my mac to run at 100BaseTX (1000BaseT has no half-duplex mode) and half-duplex causes a thirty meg file to transfer in about 2-3 seconds on both old and new Samba servers, which is much faster in the case of the new server. I doubt it's the switch, the old Samba server is running off the same switch and it's a dumb one with no management interface. However, I'll check the virtual server and virtual server host. – AlexMax Apr 13 '11 at 18:14
  • Just checked everything out with ethtool. Everything I could check was in full-duplex mode. The virtual servers themselves were only running at 10/100, not gigabit, but that shouldn't actually be slowing anything down, should it? – AlexMax Apr 13 '11 at 20:06
  • @AlexMax: the only thing that comes to mind is some sort of issue with flow control at the gigabit->10/100 transition, but I'd normally expect TCP's flow control algorithms to deal with that cleanly. When you say the virtual server is running at 10/100, do you mean that the guest VM has an emulated a 10/100 ethernet card? If so, I suppose there might be something weird happening at the emulation layer... – Gordon Davisson Apr 13 '11 at 21:46
  • Correct, the emulated card is 10/100. I'm going to try installing samba on the virtual host and see what happens. – AlexMax Apr 14 '11 at 12:57
  • You were right on the money! It's super-speedy on the host, but slow on the 'fileserver' guest. I suppose this is now a KVM question...why is this happening and how can I fix it. – AlexMax Apr 14 '11 at 13:30
  • @AlexMax: Very strange (and, unfortunately, rather outside my experience so I don't know how much more I'll be able to help). Can you pull any useful packet stats from the VM guest interface vs. the VM host interface, and maybe get a hint from that? Also, what VM are you using? – Gordon Davisson Apr 14 '11 at 14:20
  • Here is some juicy dstat information [here](http://paste.pocoo.org/show/371625/). The first dataset is what I get when I transfer files directly to the samba server on the host, the second is what I get when I transfer them to the guest from the host point of view, and the third is like the second but from the guest point of view. I am using CentOS 5.6 with kvm.x86_64 83-224.el5.centos. – AlexMax Apr 14 '11 at 16:08
  • @AlexMax: I don't see anything particularly suspicious there (other than the low throughput); the host OS shows a lot of "send" data, but I presume it's counting data forwarded to the guest in that. What happens if you connect to the guest Samba server from the host OS, and try to send a big file? Also, is there a way to switch to a gigabit (virtual) interface in the VM? – Gordon Davisson Apr 14 '11 at 20:21
  • You were the most helpful so you get the check! – AlexMax May 03 '11 at 03:43
0

The speed of virtual network card is just artifical, it's a bit stored in the "card" register and used only by the guest to display the usual "speed" status. It is never used to actually limit the actual speed of the "card", there's no code in qemu/kvm to do that - packets are always flows at the maximum possible speed. Yes different "cards" has different impact on the CPU usage and different effectiveness so that results in different speeds, but given fast enough CPU it is possible to send data at GigE speeds using 10mbps pcnet emulated NIC.

Michael Tokarev
  • 1