"Nastasi, John" <[EMAIL PROTECTED]> writes: ---
I almost thought I had the problem licked yesterday by leaving oplocks on, and utilizing the veto oplock option to selectively exclude certain file types.
Going this route, I was able to exclude both .MDB and .DBF file types with
no degradation in performance (single-user). The minute I tried to exclude
.SHP file types, however, the problem re-appeared. Using smbstatus, I came
to the conclusion that our app is attempting to gain an exclusive lock on a
specific .SHP file and, upon failing, continues to re-try at 30 second
intervals -- finally moving on after 9 minutes (20 attempts I presume).
Checking with our developers unveiled that our app is programmed in Visual
Basic and makes use of Map Objects from ESRI for GIS activities. Apparently
Map Objects is where the .DBF and .SHP (shape) files are coming into play,
and the source of the file locking problem.
Because the problem (appears) to emanate from Map Objects, I'm not sure
there's going to be a way to work around it. I'm just disappointed that it
works on an NT/2000 based share and not Samba. The client that I'm working
on this for is a large Sun user, and apparently has no real desire to drop a
Windows box into the mix.
Thanks again for your help, and if you can think of anything that may work
in this situation -- I'd be very interested in your thoughts. Although I've
not yet had the opportunity to run a TRUSS or packet capture, I can
certainly get in and learn how to do it real quick if you think that would
help in any way.
Have a good one...
John Nastasi
-----Original Message----- From: David Collier-Brown -- Customer Engineering [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 9:00 AM To: Nastasi, John Cc: '[EMAIL PROTECTED]' Subject: Re: Samba Performance on Solaris 7/8
Nastasi, John wrote:
> Do you know if there are any issues with Samba running on Solaris that
> would cause the application to run "very, very" slow with oplocks turned
> off?
No, and that's the kind of problem we should
raise with the Samba team: I'm cc'ing this
to them.> Specifically, with oplocks turned on I get acceptable performance
> trying to open an MS-Access (Jet) database. The operation completes in
> no more than a minute or so. Turning "off" oplocks (as suggested
> repeatedly by many folks for multiple users accessing an MDB on a Samba
> share) completely hoses the same operation - 9 minutes to complete.
We need to see what Samba's doing differently
between the two cases. There are three places to
look:
1) Samba logs, at log level = 3 or more
2) truss reports
3) packet dumps. I recommend them in roughly that order: I'm
good at reading truss, and the team is real good
at logs.> I've tried the configuration on a Solaris 7 (Ent 4500) running Samba
> 2.0.10 and also on a Solaris 8 (V100) running Samba 2.2.7a - same
> result. I'm about to try the latest kernel patch to see if it could be
> an fcntl related issue, but was curious if you knew of anything else
> that could be causing the problem.
>
> Based upon what I've read - oplocks being turned off should "help"
> multi-user, MDB access performance. What I'm seeing, however, is just
> the opposite.
Yes, specifically by avoiding transferring the
whole file to the client and then transferring it back.
Turning of oplocks **in principle should** cause
the db to read only the records it wants to change,
then writing them back. The times imply it's still transferring the whole
file, which is utterly evil (;-)) Of course, using
smb file locking as the mechanism to do database locking
is brain-dead in the first place. Being able to do
so is just a way of letting you try out a DBMS, get
used to it and eventually buy the back-end DBMS and
a server to put it on.
--dave
-- David Collier-Brown, | Always do right. This will gratify Sun Microsystems DCMO | some people and astonish the rest. Toronto, Ontario | (905) 415-2849 or x52849 | [EMAIL PROTECTED]
-- David Collier-Brown, | Always do right. This will gratify Sun Microsystems DCMO | some people and astonish the rest. Toronto, Ontario | (905) 415-2849 or x52849 | [EMAIL PROTECTED]
