diff options
author | Rusty Russell <rusty@rustcorp.com.au> | 2010-08-14 02:13:26 +0930 |
---|---|---|
committer | Rusty Russell <rusty@rustcorp.com.au> | 2010-08-14 02:31:22 +0930 |
commit | 11ab43084b10cf53b530cdc3a6036c898b79ca38 (patch) | |
tree | 04549a9c16f5e68349aded2f8ead56571df01312 /source4/selftest | |
parent | f00b61c7d4611802c66495824c97af6cad69704e (diff) | |
download | samba-11ab43084b10cf53b530cdc3a6036c898b79ca38.tar.gz samba-11ab43084b10cf53b530cdc3a6036c898b79ca38.tar.bz2 samba-11ab43084b10cf53b530cdc3a6036c898b79ca38.zip |
tdb: workaround starvation problem in locking entire database.
We saw tdb_lockall() take 71 seconds under heavy load; this is because Linux
(at least) doesn't prevent new small locks being obtained while we're waiting
for a big log.
The workaround is to do divide and conquer using non-blocking chainlocks: if
we get down to a single chain we block. Using a simple test program where
children did "hold lock for 100ms, sleep for 1 second" the time to do
tdb_lockall() dropped signifiantly. There are ln(hashsize) locks taken in
the contended case, but that's slow anyway.
More analysis is given in my blog at http://rusty.ozlabs.org/?p=120
This may also help transactions, though in that case it's the initial
read lock which uses this gradual locking routine; the update-to-write-lock
code is separate and still tries to update in one go.
Even though ABI doesn't change, minor version bumped so behavior change
can be easily detected.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'source4/selftest')
0 files changed, 0 insertions, 0 deletions