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.).


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.

  • Good idea, but no cigar. My ifconfig output displays media: autoselect (1000baseT <full-duplex,flow-control>) 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 1 '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 1 '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 1 '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

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:

Search here:

  • None of these config options made a difference. – AlexMax Mar 31 '11 at 15:54

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.