RE: 1.6.2 poor commit performance with large data
From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Tue, 2 Jun 2009 18:24:51 +0100
> -----Original Message-----
> This sounds like the same problem as described in [this thread]
I've had a look at this running again today. It seems to be throttled in the System process (not any of the sub-processes, so it must be a driver). On my quad-core box System.exe hits 25% CPU and stays there.
and then.... I had a brainwave. I turned off the virus checker and suddenly things went back to normal. (I use Trend which isn't quite so bad). The memory usage is still increasing at a rate of 1Mb per second but the page fault delta for System process has dropped to 0.
In the end, transferring 9500 mostly cpp source-code files (187Mb) used peak memory of 1.5Gb RAM.
If anyone wants to check the 'leak', I made a heap comparison showing the allocations. I did this using TortoiseSVN (as that has some symbols), unfortunately it doesn't have enough symbols for the svn libraries or it'd be more useful. If anyone has built SVN for Windows, and will create some .pdb symbols, then I'd be happy to re-run my commits and see if I can find out more about this issue.
It appears that the call to libapr_tsvn's apr_allocator_max_free_set is doing the damage, after transferring 130Mb (roughly 7000 files), it has 'leaked' 749Mb. I can’t see what has been calling it without some effort (and symbols) but maybe someone more knowledgeable of SVN source can offer some suggestions. It appears to mostly allocate 8k at a time, but occasionally allocates 16k (if that helps any).
Be aware I've cross-posted this to the TortoiseSVN list too.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
This is an archived mail posted to the Subversion Users mailing list.