Samba non-oplock performance on Solaris 7/8

[David Collier-Brown -- Customer Engineering]

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