WinXP<->Linux samba server test results

BG - Ben Armstrong BArmstrong at dymaxion.ca
Tue Sep 21 12:51:38 GMT 2004


Hi,

I received this private reply, but there is nothing particularly private
about these recommendations.  I think it is useful information to be
discussing on the list, so I have stricken the respondent's name in the
interests of privacy, and quoted it in its entirety.

On Mon, 2004-09-20 at 16:55 -0400, Someone wrote:
> Assuming that you are familiar with VMS the following might be of some help:

I have some familiarity, being a user & software developer on the
platform ever since our first VAX 11/750, and am working closely with my
OpenVMS sys admin, who has been a sys admin for many OpenVMS systems
over roughly the same time period, and therefore is much better versed
in tuning than I am.

> File extends are very expensive operations on OpenVMS.  Have you
> investigated your RMS defaults and insured that high water marking is turned
> off?

I asked my sys admin.  It is turned off.

> I have not done a lot of performance testing (the performance being a big
> issue with us), but do know that such can kill the performance.  We have
> benchmarked sequential file operations on VMS and the PC.  The Windows
> platform performs such much faster, but is making far fewer in process
> writes to the disk.  Basically, the on disk image in VMS is much closer to
> that in memory than the PC's. 
> 
> High water marking really slows things down since when blocks are allocated,
> the allocation operation does not finish until all of the blocks allocated
> have been zero'ed according to the established security policy.

OK.  That isn't a factor here, then.

> A large initial file size value, e.g. 2048 blocks (1MB) and a large extend
> value of 2048 (1MB) blocks will help since these are also expensive
> operations.

That's why I think OpenVMS Samba ought to be doing a better job sending
back EOF/allocation info, so the Windows client can "look ahead" further
instead of the tiny increments it is using now.

> Depending on the code with-in SAMBA, multi-buffering might help as well as
> some of the other features such as write behind.

I can't comment on that.  Would someone more familiar with the Samba
code please answer this point?

> The VMS disks should also be packed so that the files can be allocated in
> contiguous pieces.  Various of the ACP caching parameters will yield some
> incremental performance gains.

We have scheduled defragmentation running most nights.

> Slightly elevated execution priorities, large default set and working set
> sizes, etc. will also yield incremental gains in performance.

We are looking for order of magnitude increases.  I know a number of
incremental gains might help a little bit, but I suspect there is
something more fundamentally wrong here, given the discrepancy in test
times I am seeing between the platforms.

By my sysop's judgement, we have done a fair job so far ensuring the
underlying filesystem is optimized & that the OS environment (working
set, etc.) is properly tuned.

> Check to see if the SAMBA processes ever end up in any of the miscellaneous
> wait states.  These could be caused by insufficient resources.  VMS is very
> sensitive to proper system tuning.

I'll add that to the things we are watching.  Thanks.

I have noticed that SMBD seems to be constrained by DIO.  Test times
increase proportionally with decreases in available DIO to the SMBD
processes.  This is not exactly an earth-shaking revelation.

> We believe that we have our systems well tuned for most I/O intensive
> applications.  SAMBA performance is acceptable when dealing with small
> numbers of small files but degrades as the file sizes and numbers increase.
> Overall the performance of SAMBA 2.2.8 is an order of magnitude better than
> earlier versions on OpenVMS.

Be that as it may, it still falls short by an order of magnitude when
compared to Linux client -> OpenVMS server.  So it appears the Samba
server, even with our current filesystem and OS tuning measures in
place, is capable of much better performance than we are seeing.  Hence
my present line of inquiry regarding the differences in protocol
negotiation.

Ben



More information about the samba-vms mailing list