Mike Wuetherick wrote:
> 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
>>
>>
I have the same problem.
In which version is the patch contained?
regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Feb 8 14:38:13 2007