CVS update: samba/source/lib

[Volker Lendecke]

On Wed, Jul 10, 2002 at 05:06:27PM -0700, Jeremy Allison wrote:
> 
> Date:	Wed Jul 10 17:06:27 2002
> Author:	jra
> 
> Update of /data/cvs/samba/source/lib
> In directory va:/tmp/cvs-serv20748/lib
> 
> Modified Files:
> 	util.c 
> Log Message:
> *Experimental* new large-scaling printer code. Splits printing.tdb into
> a separate tdb per printer, but only keeps (currently one) tdb open at
> a time (although this is easily changed by changing a #define). Needs
> scalability testing with large numbers of printers now....
> Jeremy.

Argl. ;-) I was just thinking about a scheme to solve the Solaris fnctl
problem. Yesterday I was at a site with a large Solaris box running 2.0.9 to
make another attempt to get 2.2.5 running.  We could easily bring it to a halt
with 800 simulated clients on a 6-processor partition of an E10k. Not good. We
need 2500 possible clients. So the problem has to be solved.

Jeremy suggested semaphores, so I looked at the sysv semaphore API. It took me
about an hour just to read (not sure if I really understood it...) the manpage
of semop. 

I have several questions about the internals of tdbs:

I assume that the Solaris performance problem only happens if there are some
processes waiting on the fcntl in tdb_brlock(). What would happen if we
protected this call with a single semaphore that only allows, say, 5
simultaneous calls to fcntl? This is extremely ugly, but it's certainly minimal
invasive. Would this break anything immediately?

BTW, I got the impression that opening tdb's seems to cause severe problems. So
would it be possible to protect the locks on GLOBAL_LOCK and ACTIVE_LOCK in a
similar way?

The next iteration would be to get rid of tdb_brlock for the chains and replace
them with an array of semaphores per tdb. But then, how do I distribute the
semaphore ID's for the tdb's. With a well-known bounded number of tdb's this
would have been easy. But with tdb's per printer.... :-)

I think I'll try the easiest way first: Simply protect fcntl by a semaphore and
see if things break. I'm almost sure something will break ;-)

What do you think?

Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020711/1296fc34/attachment.bin