[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[TSVN] TSVNCache too resource intensive on large working copies

From: Peter McNab <mcnab_p_at_melbpc.org.au>
Date: 2005-05-27 12:03:57 CEST

Molle Bestefich wrote:

>Will Dean wrote:
>
>
>>I don't expect that TSVNCache is using any appreciable amount of CPU - it's
>>only disk we're competing for, really.
>>
>>
>
>Obviously, if users have DMA disabled for their IDE disks, things will
>come to a crawling halt CPU-wise even though we're only using the IO
>subsystem.
>
>So that might be worth checking out.
>
>Again, a performance test application could probably give a lot of
>hints about the affected systems:
> - How the IO subsystem generally performs
> - How much CPU is consumed when the IO subsystem is accessed
>
>So the first step could be for someone who is seeing the problem to
>collect that data.
>Well, actually, that could be the second step and the first step could
>be for "us" to find an appropriate (preferably free or shareware)
>benchmark application and collect some reference data..
>
>Or is that a completely wrong approach?
>
>
>
Several things occurred to me while reading through todays discussions.
One has been covered, i.e maybe the IDE DMA has not been enabled.
Along this vein then other possibilities are:-
No motherboard/chip set enhanced IDE drivers installed.
Bad disk defragmentation or using FAT32 instead of NTFS.
Is the O/S doing lots of virtual memory swapping between RAM and disk?
i.e. system low on memory
or maybe another application is hogging the CPU.
Is the paging file and MFT (NTFS) fragmented.?
Is the recursive search exceeding the 10 mins and never finishing?
Has a third party disk Cache program been tried like Cacheman.
One thing Cacheman does is offer the ability to turn off updating files
last time accessed, which can slow a system down if there are a lot of
small files being touched.
Has Executive Software's Diskeeper been employed to get the disk and
directory defragmentation optimized.

Seriously if someone is going to work with large repositories then some
serious CPU grunt is going to be well worth the expenditure. Stephan and
Will seem to have taken the correct approach to de-prioritizing the
Cache so the software aspect is the least intrusive.

My 2c worth.
Peter

That's all I can afford, having just taken my own medicine and upgraded
to a slick processor, 1Gb Ram.
and I do run and recommend Cacheman and Diskeeper.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri May 27 12:04:17 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.