On 04/09/2010 17:33, Justin Erenkrantz wrote:
> Aha. Adding exclusive locking into our pragma
> [http://www.sqlite.org/pragma.html] calls in "svn_sqlite__open":
>
> "PRAGMA locking_mode=exclusive;"
>
> brings the time for "svn st" down from 0.680 to 0.310 seconds. And,
> yes, the I/O percentages drop dramatically:
>
> ~/Applications/svn-trunk/bin/svn st 0.37s user 0.31s system 99% cpu 0.684 total
> ~/Applications/svn-trunk/bin/svn st 0.26s user 0.05s system 98% cpu 0.308 total
>
> I *think* we'd be okay with having Sqlite holding its read/write locks
> for the duration of our database connection rather than constantly
> giving it up and refetching it between every read and write operation.
> As I read the sqlite docs, we should still be able to have shared
> readers in this model - but, it'd create the case where there were
> idle shared readers (due to network I/O?) would block an attempted
> writer. With a normal locking mode, a writer could intercept a reader
> if it were idle and not active. However, I'd think our other locks
> would interfere with this anyway...so I think it'd be safe.
>
> Thoughts? -- justin
I think it's essential to use exclusive locking for performance reasons,
without it we will get just as many individual file ops as in 1.6 (and
it's the number of file ops which causes the performance problem on
windows).
I got the same results as you pre single-db in this message (near the
end of it), and the other message from me in that thread:
http://svn.haxx.se/dev/archive-2010-02/0239.shtml
For fun you can try 'locking_mode=MEMORY' which makes it go really
really fast (but unsafe wrt atomic operations under certain termination
conditions).
Matthew
Received on 2010-09-06 15:07:58 CEST