On 10/27/11 14:13, Philip Martin wrote:
> Mark Phippard<markphip_at_gmail.com> writes:
>
>> 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?
> Yes, number of transactions matters a lot. However upgrade is a special
> case that runs in a single SQLite transaction as this makes most
> upgrades faster. Maybe for really large upgrades the huge transaction
> is a problem? My 100,000 node working copy upgrades in 45 minutes.
I don't have too much files/directories either, currently: 1772120,
that's only an order of magnitude bigger.
What I could see is that svn's memory usage has grown constantly during
the operation. It started on about 20M resident and went to
approximately 60-80M.
I don't know for sure because I lost the interest in watching it in
about 3-4 days, so I'm just extrapolation from the last seen value
(sixty something megabytes on day 3). :)
> Upgrade does a number of read queries as well as writes, but all within
> the same transaction.
>
I guess, you are right, maybe the big transaction caused the major
slowdown.
Received on 2011-10-27 14:33:57 CEST