On Mon, Jun 25, 2012 at 10:31 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> Attila Nagy <bra_at_fsn.hu> writes:
>>
>> > I suffer from the slowness of svn rm since the upgrade to 1.7 from
>> > 1.6, but I couldn't find the time to profile it until now.
>> > My setup is: FreeBSD 9-STABLE/amd64 with zfs, eight fast cores, SAN,
>> > 32 GiB of RAM.
>> > Versions:
>> > svn, version 1.7.5 (r1336830)
>> > sqlite: 3.7.12.1 2012-05-22 02:45:53
>> > 6d326d44fd1d626aae0e8456e5fa2049f1ce0789
>>
>> > Any ideas about how could it be made even faster without ditching
>> > sqlite? Deleting 100 files and committing the change shouldn't take 40
>> > (10, with the above indexes) minutes, even with 2 million files... I
>> > guess.
>>
>> SUbversion 1.8 (trunk) has various speed improvements to the working
>> copy library. Is your working copy on the SAN? Depending on how the
>> SAN works you may find that the exclusive locking patch in issue 4176
>> helps: http://subversion.tigris.org/issues/show_bug.cgi?id=4176
>
> This sounds like the scalability problem that was fixed by upgrading Sqlite
> 3.7.9 or later.
> (Without that we perform a full table scan, which in this case would be 2
> million times (the number of nodes) slower than deleting with the proper
> index usage)
He said he is using 3.7.12.1
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-06-25 16:33:24 CEST