I see this alot (ie the TSVNcache / explorer) issue regularly with
larger subversion projects that we have - ie thousands of files,
potentially 10-15 Gb repositories.
Even navigating a directory structure becomes so slow that I've taken to
even uninstalling TSVN if I just need to grab a copy of a file in a
repository that I haven't browsed recently.
From my experience, this seems to happen more with projects that
haven't been browsed recently - TSVN wants to 'update the cache' and
slows down everything to the point of being unusable. I have directory
cacheing disabled (a workaround I spotted from previous discussions
about this), which helps in general, but then if I try to browse a
particular local repository, it can end up stalling explorer and again,
making whole directory tree's unreachable unless I disable TSVN (ie
uninstall it temporarily).
I should note that alot of our repositories are fairly large - local
size (including all of the .svn directories) can run 20-30Gb - and
contain a LOT of binary data - 3d models / textures etc. Many of these
files can be fairly large themselves - 15-30 Mb for a single PSD file
for example.
Could the size of these files and/or the fact that they are binary be
affecting things?
I'll try an update to a more recent client and see if this helps.
Mike W
GDGi
Stefan Küng wrote:
> Matthew Ratzloff wrote:
>
>> I've run some more extensive testing to figure out the problem. Here
>> are the results.
>>
>> 1. I disabled ALL non-Microsoft shell extensions. There were only
>> three: iTunes, Anapod Explorer, and VDMSound. Only the first two are
>> in common between this machine and my work machine (otherwise, my home
>> machine and work machines are fairly different).
>>
>> I checked out a repository and watched the CPU usage. At first,
>> TortoiseProc.exe was running at about 50-70%, with occasional spikes
>> from TSVNCache.exe. About halfway through, explorer.exe (the main
>> process, controlling the Start Menu and desktop) began to climb until
>> it was about 90%. The download also slowed down considerably. I
>> killed the explorer.exe process, the checkout sped up, and everything
>> worked fine. When I opened the folder with the checked-out files, it
>> opened immediately. However, it only did this because I killed the
>> explorer.exe process.
>>
>> 2. Next, I also disabled my real-time virus scanner. I checked out
>> the repository. The results were identical. This time, however, I
>> did not kill the explorer.exe process prior to completion. It
>> completed, and I clicked on the folder to see the files. No files
>> displayed, and explorer.exe stability overall began to decline and
>> usage increase. At this point, I suspected TSVNCache.exe had some
>> role, so I killed it. It didn't do anything. I killed explorer.exe.
>> The folder and files immediately displayed fine. Not entirely
>> convinced about TSVNCache.exe.
>>
>> 3. I opened a folder view window and ran "svn co" from the command
>> line. Briefly, TSVNCache.exe jumped to the top of the CPU usage and
>> then explorer.exe jumped to 80-90% usage. I killed them all and began
>> again.
>>
>> 4. This time I closed all folder view windows and killed TSVNCache.exe
>> prior to doing anything (call it a pre-emptive strike). I ran "svn
>> co" from the command line. No explorer.exe CPU jump. I opened a
>> folder view window after the checkout completed. No explorer.exe CPU
>> jump. I click in the folder itself and everything is fine.
>>
>> And the clincher:
>>
>> 5. I opened a folder view window and killed TSVNCache.exe. I then
>> used TortoiseSVN to check out a repository as I watched the processes
>> and CPU usage. The checkout completed normally, and explorer.exe
>> never spiked. I then clicked on the folder. TSVNCache.exe started
>> up, but still explorer.exe never spiked. The icons had no overlays.
>> I refreshed the folder contents and the overlays appeared. Even then,
>> explorer.exe CPU usage didn't spike.
>>
>> So the problem is TSVNCache.exe. At a certain point during a checkout
>> or update, TSVNCache.exe briefly influences explorer.exe in some way
>> that makes it consume as many cycles as possible. If it's not
>> running, no spike occurs. I can reproduce this 100% of the time. I
>> also want to stress that explorer.exe simply does not do this at all
>> unless I run an update or checkout with TortoiseSVN. I can literally
>> not use the interface for weeks, and the one time I do it immediately
>> causes a problem.
>
> Thanks a lot for the expensive testing.
> There's a problem though: I've now tried over three days several hours
> to reproduce this. While I could make the explorer process to use a lot
> of CPU, I never got it to use 100% CPU. Sure, sometimes during a
> checkout it would use a lot of CPU, but after the checkout was finished
> it was ok again.
> I've used different repositories to check out from. I even used my
> locally mirrored TSVN repository and checked out from its root, just to
> get a *huge* working copy. But even then, the explorer process would not
> get locked at 100% CPU.
>
>
>> Finally, even though I'm the only reporting it, that doesn't really
>> mean anything. Some others might be experiencing this, but it's
>> entirely possible that I'm the only one who a) didn't immediately
>> uninstall it the first couple of times it occurred, and b) took the
>> time to report it as a bug.
>
> In my experience, there are so many people out there using TSVN that if
> such a problem really was wide spread, I would hear about it at least
> twice a day.
>
>> Thanks for looking into this. I appreciate everyone's hard work.
>
> The only thing I can think of is that the cache (TSVNCache) process
> sends update notifications to the shell to tell it about status changes.
> The shell uses those notifications then to update the overlay icons.
>
> What I've seen happen sometimes is that the shell doesn't like to be
> "pushed". If too many notifications are sent to the shell process, then
> the shell can really lock up. But I only got this to happen if I write a
> little test tool which sends such notifications at full speed in a
> while-loop, and only if it sends more than about a hundred of them.
>
> Maybe you have a much faster computer than I have? Because during
> checkouts/updates/... the cache will send such notifications for many
> files (during a checkout for every file), but not fast enough that the
> shell would take this personally :) At least on my computer.
>
> Anyway: I've put a Sleep(0) call in the Cache function where the shell
> notifications are sent. That will prevent the cache from sending too
> many notifications too fast.
> Can you try a nightly build and see if the problem is still there? Or at
> least a little bit better?
>
> Stefan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Feb 4 05:32:52 2007