On 06/25/12 15:04, Philip Martin wrote:
Attila Nagy <b...@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... :)
