[Samba] Samba - XP performance problem
David Beck
After having googled the whole internet for days I decided to go public
with this issue.
The result of my google queries so far is that there are plenty of
others with the very same problem I have and noone posted a reasonable
answer to this:
Using Samba 3 with XP gets bad performance. I tested this on Tru64 5.1b
and FreeBSD 5.3 with the very same symptoms.
The throughput bw XP and Samba goes up and down. It starts transfering
with a reasonable speed and after having transfered around 16 megs it
slows down.
I tried many configuration options regarding locking, tcp settings, xmit
size and every combination that could make any sense for me.
Then I gave up with this configuration mess as I could lower the
performnce easily, but the performance jittering was the same.
Now a few notes before I continue: I tested the FreeBSD server on the
loopback interface and the file write speed was around 43 Megs that is
close to the disks maximum. I also tested the XP machine with a Windows
server and the write performnce was around 10 Megs on a 100Mbit link. In
addition to that the FreeBSD machine is at my home and the Tru64 and the
Windows server are where I work. I'm pretty sure that this is not a
network issue.
After spending a lot of time with investigation I decided to go deeper
in this issue. I installed ethereal to capture the traffic and compare
the results bw XP-Windows and XP-Tru64. The test was to copy 50Meg file
to both servers and capture the packets. To my surprise the conversation
was quite different.
XP-Windows (excerpt):
- nt create and x
- trans2: query file info internal
- set file info
- tcp data stream...
XP-Samba (excerpt):
- nt create and x
- trans2: query file info internal
- (query file info + write and x request) many times, incresing offset,
one byte length
- tcp data stream....
In case of XP-Samba, the last two steps are repeated many times.
Large part of the effective bandwith is filled with query file info and
1 byte writes.
The packet data can be downloaded from these links:
http://dbeck.beckground.hu/download/xp-samba.bz2
http://dbeck.beckground.hu/download/xp-win.bz2
I also made a screenshot of a bandwith monitor to show what I mean by
performance jittering:
http://dbeck.beckground.hu/download/samba-performance-write.PNG
http://dbeck.beckground.hu/download/samba-performance-read.PNG
Please note that the original packet log for the 50 Meg file was very
large, so I kept only the interesting parts.
Last, could anyone there, Samba and SMB wizards help me, how to solve
this performance issue?
Thank you in advance,
David.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
Jeremy Allison
Can you send me the ethereal capture traces please ? I have a theory...
Jeremy.
Jonathan Johnson
having stale "connections" to non-existent servers can cause a
performance issue when browsing. Here's a couple of things to try:
1) Remove any shortcuts to non-existent network locations -- this
applies to broken mapped drives, shortcuts on the desktop and in My
Documents, and shortcuts in My Network Places
2) Look in the registry at
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 (or
...\MountPoints) -- Under this key, there will be several subkeys. Some
of these are in the form of ##Server##Share -- if there are any of these
that refer to nonexistent servers or shares, remove them. DO NOT remove
any of the other keys, else your system might not boot properly. This
key is seems to be the Windows version of the /etc/fstab file.
Nevertheless, I'm glad to see that you found something interesting.
Hopefully, your research will help the developers solve some other
nagging problems!
--Jonathan Johnson
David Beck wrote:
> In case of XP-Samba, the last two steps are repeated many times.
> Large part of the effective bandwith is filled with query file info
> and 1 byte writes.
>
> The packet data can be downloaded from these links:
>
> http://dbeck.beckground.hu/download/xp-samba.bz2
> http://dbeck.beckground.hu/download/xp-win.bz2
>
> I also made a screenshot of a bandwith monitor to show what I mean by
> performance jittering:
>
> http://dbeck.beckground.hu/download/samba-performance-write.PNG
> http://dbeck.beckground.hu/download/samba-performance-read.PNG
>
> Please note that the original packet log for the 50 Meg file was very
> large, so I kept only the interesting parts.
>
> Last, could anyone there, Samba and SMB wizards help me, how to solve
> this performance issue?
>
> Thank you in advance,
>
> David.
>
David Beck
Followup for the performance issue:
The trace shows that the conversation changes right after the "trans2:
query file info internal" stage, so I looked into the samba code at this
file:
case SMB_FILE_INTERNAL_INFORMATION:
/* This should be an index number - looks like
dev/ino to me :-)
I think this causes us to fail the IFSKIT
BasicFileInformationTest. -tpot */
DEBUG(10,("call_trans2qfilepathinfo: SMB_FILE_INTERNAL_INFORMATION\n"));
SIVAL(pdata,0,sbuf.st_dev);
SIVAL(pdata,4,sbuf.st_ino);
data_size = 8;
break;
The comment speaks for itself. I suspect the 8 byte here contains some
magic that makes XP behaves as I found.
I made an other experiment: I turned off the oplock support ("Oplocks =
No") and this made XP behave like if it was talking to a Windows server.
No extra tran2 calls and 1 byte writes. The performance got better
because the slowdowns disappeared, but it was still slower compared to
the windows machine.
Then I looked into the traces again and found that XP sends 1260 bytes
in each packets when talking to the windows server and 536 bytes when
talking to the samba server. The MTU is 1300. I suspect, this issue may
be related to the different subnets where the two machines are located.
Hope this helps someone out there,
David.
Jeremy Allison
--cmJC7u66zC7hs+87
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Aug 10, 2005 at 11:05:06AM +0200, David Beck wrote:
> Thank you for the suggestion. I'll keep the info for reference.
>
> Followup for the performance issue:
>
> The trace shows that the conversation changes right after the "trans2:
> query file info internal" stage, so I looked into the samba code at this
> file:
>
> http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_3_0/source/smbd/trans2.c?rev=8959&view=markup
>
> case SMB_FILE_INTERNAL_INFORMATION:
> /* This should be an index number - looks like
> dev/ino to me :-)
>
> I think this causes us to fail the IFSKIT
> BasicFileInformationTest. -tpot */
>
> DEBUG(10,("call_trans2qfilepathinfo:
> SMB_FILE_INTERNAL_INFORMATION\n"));
> SIVAL(pdata,0,sbuf.st_dev);
> SIVAL(pdata,4,sbuf.st_ino);
> data_size = 8;
> break;
>
> The comment speaks for itself. I suspect the 8 byte here contains some
> magic that makes XP behaves as I found.
Hmmm. Good detective work. One thing I'd like to check though - can you try the
following (not production) patch and recompile and test please ? I'm
still at LinuxWorld and so won't be able to get to this until tomorrow
at the earliest.
If this fix makes things go faster I have a working theory...
Jeremy.
--cmJC7u66zC7hs+87
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=look
Index: smbd/dosmode.c
===================================================================
--- smbd/dosmode.c (revision 9229)
+++ smbd/dosmode.c (working copy)
@@ -22,11 +22,13 @@
static int set_sparse_flag(const SMB_STRUCT_STAT * const sbuf)
{
+#if 0 /* JRATEST */
#if defined (HAVE_STAT_ST_BLOCKS) && defined(STAT_ST_BLOCKSIZE)
if (sbuf->st_size > sbuf->st_blocks * (SMB_OFF_T)STAT_ST_BLOCKSIZE) {
return FILE_ATTRIBUTE_SPARSE;
}
#endif
+#endif
return 0;
}
--cmJC7u66zC7hs+87
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
--cmJC7u66zC7hs+87--
Jeremy Allison
> >>
> >>deeper in this issue. I installed ethereal to capture the traffic and
> >>compare the results bw XP-Windows and XP-Tru64. The test was to copy
> >>50Meg file to both servers and capture the packets. To my surprise
> >>the conversation was quite different.
> >>
> >>XP-Windows (excerpt):
> >>- nt create and x
> >>- trans2: query file info internal
> >>- set file info
> >>- tcp data stream...
> >>
> >>XP-Samba (excerpt):
> >>- nt create and x
> >>- trans2: query file info internal
> >>- (query file info + write and x request) many times, incresing
> >>offset, one byte length
> >>- tcp data stream....
> >>
> >>In case of XP-Samba, the last two steps are repeated many times.
> >>Large part of the effective bandwith is filled with query file info
> >>and 1 byte writes.
I can't reproduce this on my XP vmware session. *exactly* how are
you getting this traffic pattern ?
Jeremy.
Jeremy Allison
>
> Followup for the performance issue:
>
> The trace shows that the conversation changes right after the "trans2:
> query file info internal" stage, so I looked into the samba code at this
> file:
>
> http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_3_0/source/smbd/trans2.c?rev=8959&view=markup
>
> case SMB_FILE_INTERNAL_INFORMATION:
> /* This should be an index number - looks like
> dev/ino to me :-)
>
> I think this causes us to fail the IFSKIT
> BasicFileInformationTest. -tpot */
>
> DEBUG(10,("call_trans2qfilepathinfo:
> SMB_FILE_INTERNAL_INFORMATION\n"));
> SIVAL(pdata,0,sbuf.st_dev);
> SIVAL(pdata,4,sbuf.st_ino);
> data_size = 8;
> break;
>
> The comment speaks for itself. I suspect the 8 byte here contains some
> magic that makes XP behaves as I found.
>
> No") and this made XP behave like if it was talking to a Windows server.
> No extra tran2 calls and 1 byte writes. The performance got better
> because the slowdowns disappeared, but it was still slower compared to
> the windows machine.
Ok, I'm using the "disk test" part of www.passmark.com and can reproduce
the "1 byte write every 64k followed by a qfilinfo" call against Samba,
latest SVN code - but it also does the same against my Windows 2003 SP1
server....
BTW: - just using a cmd.exe prompt "COPY" command or using cut and
paste from a Windows explorer Windows doesn't reproduce this problem,
that writes completely normally.
What Windows server are you using ? It looks like a reported allocation
issue to me - but I'm still trying to understand what triggers this
behaviour in the client ?
Jeremy Allison
>
> Ok, I'm using the "disk test" part of www.passmark.com and can reproduce
> the "1 byte write every 64k followed by a qfilinfo" call against Samba,
> latest SVN code - but it also does the same against my Windows 2003 SP1
> server....
Looking closely, the "disk test" here does the 1 byte per 32k write
until it's set the "full size" for the test - then does writes. The
"full size" for the test seems to be related to the size of the
underlying disk you're testing.
I don't see a difference in behaviour between Samba3 and W2K3
here with an XP client.
David Beck
with that. You are right, it does not show the performance problem.
I used Total Commander for copying the files, so I looked into the
configuration options and found that it has some "way too smart" options
for copying files. It used small buffers to speedup the transfer of
small files (default option). If I set compatibility mode for the Samba
drive then it works fine.
Sorry for wasting your time and thank you for the tests you made. That
helped.
Best regards,
David.
PS: TC: Crap software of a crap architecture.
Jeremy Allison wrote:
>On Thu, Aug 11, 2005 at 11:50:25PM +0200, David Beck wrote:
>
>
>>I copied large files. First I tried a CD image around 600 Megs. Later I
>>realized that 50 Megs is good enough for testing this.
>>I think anything around 25 Megs would do.
>>
>>
>
>Exactly how did you copy them ? I'm using a 200Mb file and don't see it.
Alan Dodd
WinCommander) and consider it a very useful and well made program.
Among other features it can act as an ftp client, file compare by
contents, and you can transfer files between two pc's through lpt ports
(laplink cable), even win3.1 <-> winxp (there is a 16 bit version).
It's not free.
A.D.
Jeremy Allison
> Ooops. I tried with copy from the cmd shell and made a few experiments
> with that. You are right, it does not show the performance problem.
>
> I used Total Commander for copying the files, so I looked into the
> configuration options and found that it has some "way too smart" options
> for copying files. It used small buffers to speedup the transfer of
> small files (default option). If I set compatibility mode for the Samba
> drive then it works fine.
>
> Sorry for wasting your time and thank you for the tests you made. That
> helped.
No problem, that helps a lot to know we don't have a performance issue
here.
> Best regards,
> David.
>
> PS: TC: Crap software of a crap architecture.
On that we *both* agree :-).
Jeremy.