[Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)

[Igor]

Hello Stan,

Friday, January 22, 2010, 2:26:41 AM, you wrote:


Check it out, I found it with google:

http://oreilly.com/catalog/samba/chapter/book/appb.pdf

You see "out of the box" there is about 20% difference between SMB and
FTP performance which corresponds with your experience.



SH> Hello fellow Samba users and devs.  This is my first post.  I've searched
SH> documentation far and wide for Windows, Linux, and Samba, and have not been able
SH> to shed any light on this issue.

SH> I can't get more than 8MB/s during a single file copy stream out of my Samba
SH> server over my 100FDX switched network either from Win2K or WinXP (I don't have
SH> a *nix client to test with).  The network is idle during testing.  Via FTP on
SH> these Win machines to/from the same filesystem (100GB XFS) as the Samba share I
SH> consistently get just a shade over 11MB/s.  However, if I launch two
SH> simultaneous file copy streams from Windows Explorer or from the command line, I
SH> hit the 11MB/s I see via FTP.  Interestingly, if I launch a file copy with the
SH> source file being on one smb share on the server, and the destination being
SH> another smb share (separate filesystem) on the server, the combined throughput
SH> is also 8MB/s, 4 up and 4 down, which is very strange as this should be two
SH> distinct streams.  I can copy files between the Win2K and WinXP machines at just
SH> over 10MB/s in a single stream and max out the 11MB/s with two streams.

SH> I've tweaked every relevant Windows registry setting I can identify, and I've
SH> tried all combination of the following smb.conf settings with various buffer sizes

SH> max xmit = 65535
SH> socket options = TCP_NODELAY
SH> socket options = SO_SNDBUF=262144 SO_RCVBUF=262144
SH> socket options = IPTOS_LOWDELAY

SH> and none of these tweaks make a difference.  Still only 8MB/s with a single stream.

SH> I've eliminated the network hardware and any CPU/mem/disk bottlenecks on the
SH> server and workstations as possible causes.  The machines are all much more
SH> powerful than the minimums required to fully saturate a 100FDX network.

SH> I don't know if the problem lies with the Windows clients or with smbd.  The one
SH> thing that is certain is that this is a single stream performance issue.
SH> Launching multiple copy streams maxes the network just as FTP does.  Why is
SH> 3MB/s of free bandwidth being left on the table for single stream operations to
SH> from smbd?

SH> Any/all hints comments are welcome.  I've burned many hours on trying to figure
SH> this out to no avail, and if I had any hair I'm sure I'd have pulled much of it
SH> out troubleshooting this. ;)  I'd really like to max out that single stream
SH> performance.

SH> Thanks.

SH> -- 
SH> Stan



-- 
www.rol.ru
Best regards,
 Igor                            mailto:sprog at online.ru