On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy <b...@fsn.hu> wrote: > On 10/26/11 15:37, Philip Martin wrote: > > Attila Nagy <b...@fsn.hu> <b...@fsn.hu> writes: > > > I'm trying to update a working copy of some tens of GBs with svn 1.7.1 > > Did you upgrade with 1.7.0 or 1.7.1? > > I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm > currently using. > The upgrade took nearly one week (I can't afford a clean checkout, because > I have to preserve the files' inode numbers), at the start it was running > very fast, and at the end of the week it could print a new directory in > every 8-10 seconds, while the svn processes CPU usage was 100%. > The disks weren't touched, it seems that even with a database completely in > the OS's buffer cache the SQL operations are pretty slow with a lot of > files. > Could it be because some indexes are missing (or not optimized for this > amount of files), or it is what we could get from SQLite? >
I can see where having all that RAM could help greatly when the database is being read, but I do not see how it would help when we are writing to the database. I would imagine the database does stuff to flush itself to disk whenever a transaction is committed. I thought this was why we see 1.7 slower than other versions via NFS, even on small working copies where the database would fit in anyones RAM. I would imagine svn upgrade is almost entirely writes and I recall it does quite a few transactions. So couldn't the linear slow down just be based on the growth in the amount of bytes that are written to disk each time? -- Thanks Mark Phippard http://markphip.blogspot.com/
