tdb_lock failed

[John H Terpstra]

On Wed, 29 Oct 2003, Brandon Craig Rhodes wrote:

> 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.

Since I am the person who set the recommendation, please let me explain.

Most sites I have been exposed to that have more than 250 users need
mulitple Domain Controllers. With Samba this thus requires at least one
BDC. Tdbsam is not capable of being replicated. Ldapsam can be configured
for distributed Domain Controller operation (PDC+BDCs).

If you do not require more than a single DC (I would suspect you will with
20,000 users) then there is no reason to avoid tdbsam. In fact, from my
performance tests (qualitative only) tdbsam is much faster with only 4,000
entries.

>
> 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,
>


- John T.
-- 
John H Terpstra
Email: jht at samba.org