tdb_lock failed

[Brandon Craig Rhodes]

Brandon Craig Rhodes <brandon at oit.gatech.edu> writes:

> Now we are having extensive problems with performance ... because of
> contention over the secrets.tdb file from which each thread must now
> fetch the SID for our domain controller ... This is happening in two
> different labs under both Solaris 2.7 and 2.8 and renders samba-3
> essentially unusable.

Because others indicated to me that they encounter problems like this
I wanted to provide an update regarding what we had learned.

My currently hypothesis is that our bottleneck is our 23,000 entry
smbpasswd file.  Under "security = server" the password server seemed
able to handle the load of our clusters, but under that scheme the
cluster samba server would open many connections to the password
server - one for each client, in fact - and perform authentications in
parallel.

Under "security = domain", it appears that connections from the client
samba are serialized - only one can be made at a time, no matter how
many PC's are waiting to mount shares.  This seems to be (?) because
each client thread locks the server's records in secrets.pdb.  Since
the negotiation could result in the shared secret being renegotiated,
locking it is a quite reasonable restriction; but it means that while
one thread was being served by the password server, all the other
threads in the cluster had to hang around on the fcntl lock and wait
for the record to become available.

So the fact that fifty threads were sitting on the lock on the cluster
server seems merely to have been a symptom that the password server
was not answering their responses quickly enough.  Since the HOWTO
does not suggest using passdb.tdb with more than 250 users, I am now
trying to get an ldap solution working for password lookups.

I will report back to the group on whether this solves the problem.
But, to conclude, I do not believe the lock contention was due to
problems with the locks themselves; once I had applied the Solaris
patches for Solaris bug 4735093, I had no further evidence that the
locks themselves were a problem.

But we will see,
-- 
Brandon Craig Rhodes                         http://www.rhodesmill.org/brandon
Georgia Tech                                            brandon at oit.gatech.edu