On 06/09/2010 15:18, Bert Huijben wrote:
-----Original Message-----
From: Matthew Bentham [mailto:mj...@artvps.com]
Sent: maandag 6 september 2010 15:07
To: Justin Erenkrantz
Cc: Bert Huijben; Greg Stein; Johan Corveleyn; Subversion Development
Subject: Re: Worried about single-db performance
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).
Did you actually try a shared lock before suggesting this?
I haven't re-run those tests on single-db. The results I linked to
compare locking_mode=NORMAL and locking_mode=EXCLUSIVE on otherwise
identical code.
Getting a shared lock actually gives me better performance on this read only
operation then an exclusive lock and it doesn't block out other clients
(which would be a breaking change from 1.6)
I understand locking_mode=EXCLUSIVE to allow shared read-only access.
Don't we block write access when other clients are reading already? Or
are you worried about where we're releasing the database connection?
I'm surprised locking_mode=NORMAL could ever have better performance
given that the number of lock operations must be strictly greater and
everything else is the same.
Getting an exclusive lock on every operation would completely disable
Subversions most popular client: TortoiseSVN.
I didn't realise this, you are of course right that that would make it
unacceptable. I don't really understand why it would break TortoiseSVN,
does it take write access and then not release it somehow?
Matthew
