TDB locking overhead and performance...

[Daniel J Blueman]

I did some smbd profiling, and was seeing quite a lot of time spent
(un)locking [1] TDB files.

A quick workload of opening a few directory trees, we see a _lot_ of
activity with a few TDB files:

locking.tdb: 11943 accesses
brlock.tdb: 690 accesses
group_mapping.tdb: 126 accesses
account_policy.tdb: 20 accesses

As a test, I changed the opening of the locking.tdb and brlock.tdb
files to use the TDB_INTERNAL flag, avoiding use of the fcntl(F_SETLK)
syscall for locking individual database records. Performance was a lot
snappier, with quite a bit less system time used.

What is the scope of implementing shared memory TDBs, where locking
could be done simply on structures?

--- [1]

fcntl64(9, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=34456,
len=1}, 0xafee2a74) = 0
fcntl64(9, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=34456,
len=1}, 0xafee2ac4) = 0
--
Daniel J Blueman