tdb_lock failed

[Andrew Bartlett]

On Thu, 2003-10-30 at 03:03, 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.

So, did you try and run winbind on these member servers, as suggested?

One of it's roles in life is to fix *this exact* issue.  It too
serialises the connections to the DC, but does so on a single TCP/IP
connection, which means that there are less than 1/10 the packets, and
*far* less latency.   

Andrew Bartlett 

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20031030/ab2088e5/attachment.bin