On Mon, Jun 25, 2012 at 10:31 AM, Bert Huijben <b...@qqmail.nl> 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 > > 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/
