Samba Performance on Solaris 7/8

[David Collier-Brown -- Customer Engineering]

"Nastasi, John" <john.nastasi at ieminc.com> 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:David.Collier-Brown at Sun.COM]
Sent: Tuesday, March 11, 2003 9:00 AM
To: Nastasi, John
Cc: 'davecb at canada.sun.com'
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       | davecb at canada.sun.com



-- 
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       | davecb at canada.sun.com