On 06/09/2010 15:18, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Matthew Bentham [mailto:mjb67_at_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
Received on 2010-09-07 13:48:51 CEST