On 06/25/12 15:04, Philip Martin 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
>
SAN means, the file system is on an (FC)SAN, I've included it in my
e-mail because most people associate these three characters with "fast".
And indeed, the working copy is on a tiered (SLC SSDs in the first tier,
15kRPM SAS disks in the second) storage, which is fast.
Otherwise this counts as a DAS, with single disk, non-shared file system
semantics (ZFS is used here).
So I don't think I have any locking issues, sqlite does full table scans
with 2 million files, that is what hits me (placing two indexes gives 4x
speedup).
BTW, I've tried trunk and got very impressive results for the "delete
100 files" test:
# time svn rm test*
0.057u 0.082s 0:00.15 86.6% 240+2470k 0+191io 0pf+0w
# time svn commit -m 't'
0.104u 0.216s 0:02.66 11.6% 237+2575k 0+3872io 0pf+0w
This ran for 40 minutes on 1.7.5 (and 10 minutes with my two additional
indexes).
Great job, thank you!
ps: I hope trunk is stable enough now for general daily usage... :)
Received on 2012-06-25 16:34:24 CEST