Volker.Lendecke at SerNet.DE
Sun Feb 4 22:58:37 GMT 2007
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20070204/14d9d84f/attachment.bin
More information about the samba-technical