summaryrefslogtreecommitdiff
path: root/codepages
diff options
context:
space:
mode:
authorRusty Russell <rusty@rustcorp.com.au>2010-08-14 02:13:26 +0930
committerRusty Russell <rusty@rustcorp.com.au>2010-08-14 02:31:22 +0930
commit11ab43084b10cf53b530cdc3a6036c898b79ca38 (patch)
tree04549a9c16f5e68349aded2f8ead56571df01312 /codepages
parentf00b61c7d4611802c66495824c97af6cad69704e (diff)
downloadsamba-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 'codepages')
0 files changed, 0 insertions, 0 deletions