On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy <bra_at_fsn.hu> wrote:
> On 10/26/11 15:37, Philip Martin wrote:
>
> Attila Nagy <bra_at_fsn.hu> <bra_at_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/
Received on 2011-10-27 13:48:29 CEST