tdb performance

[Volker Lendecke]

On Mon, Feb 05, 2007 at 11:47:53AM +1100, tridge at samba.org wrote:
>  > We'd have to be more careful with a correct tdb_close() on
>  > the db's that do it. In tdb_close() I would clean up the
>  > records I did not really delete but just mark.
> 
> still relies on us doing a clean close, no? :)

In the sense that tdb records are put on a freelist in a
timely manner, yes. But if we modify tdb_free() to also look
at DEAD records as merge candidates, then I would think that
we don't really have records pile up.

This would be a problem with the static tdb's where records
are not typically deleted like the winbind idmap file. There
it could happen that a dead record is never seen by
tdb_free() because the adjacent ones are never deleted. But
my feeling (no test so far :-)) is that the records in
locking.tdb are so short-lived that the DEAD records will
eventually be picked up.

> it could help on delete, but won't help on allocate.

Hmmm. Allocate would stress the freelist a lot less because
every process has a little cache of its own freelist entries
around. And if we leave the records in the hash chains then
another process might just re-use the DEAD record when
it saw one while traversing the hash chain.

Hey, what about the following: A freelist per hash chain --
easy! Just put the unused records at the end of the valid
hash chain entries. This way they don't get into the way of
the searches and we don't have to bother the central
freelist that much. We would not have to keep state in the
client if we agree that up to n dead records are allowed at
the end of each hash chain.

> The simplest way I can think of to measure contention is
> this:

I'll look at this, thanks :-)

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20070205/99695ba2/attachment.bin