tdb performance

[Volker Lendecke]

Hi!

Today I watched smbd with strace under nbench load. It seems
that tdb_delete is not the cheapest operation. It has 3
nested lock/unlock pairs. The hash chain, the record itself
for protection against races with traverse, and then the
freelist. Then I remembered one of our biggest scalability
problems: The freelist in connections.tdb.

What do you think about the following: We do a "lazy"
tdb_delete. Every process just marks the record it is about
to delete as dead. If this process is about to tdb_insert
something that fits, we have space in the tdb available. If
a second record is about to be deleted, we actually do the
delete on one of both. Not sure which one to pick, the
earlier, the smaller?

I think this has the potential to reduce contention on the
freelist considerably, in particular as we have quite a few
short-lived share mode records these days, look for example
at can_delete().

An obvious extension we would have to do is to properly
clean up the records marked as dead in case a process dies.

What do you think? Worth spending some time on? Might be
simpler to implement than multiple freelists.

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/20070204/14d9d84f/attachment.bin