Re: TortoiseProc.exe hangs sporadically during update.

On 21.05.2015 16:13, Terry Dooher wrote:
> We're seeing an issue that's biting a few of our users at the moment.
> It has been intermittent, but I've managed to observe this on a
> client system over the course of an afternoon's work.
>
> We have a large repo containing many binary assets. (Full working
> copy is ~270GB, including pristine, though we've scripts to assist
> with sparse checkouts for most users). When updating an existing
> working copy (about 50 revisions old, roughly a day's work), the
> update will proceed as normal for a random amount of time and the
> throughput will then drop to 0 kb/s and never recover.
>
> TortoiseProc when running normally will tick over at < 1% CPU. The
> moment it hangs, this ramps up to saturate a full hardware thread and
> stays there. RAM usage is at ~60MB. Using procmon/procexp shows that
> once it hits this state there isn't a single further byte of network
> or disk I/O. The process has to be killed, the WC cleaned up and the
> update retried. This works for a while; sometimes it succeeds,
> sometimes it lasts as little as 20 seconds before it hangs again.
>
> There's no pattern I can discern in timing, number of changed files,
> . The last file shown in the log (or the next one listed in the repo)
> will be small, large, text or binary. Looking at the process threads
> in procexp, I can see the 99.99% of the CPU cycles going on:
> MSCVR110.dll!endthreadex+0x90 With a <.01% on TortoiseProc.exe. This
> ties up with what procmon shows: lots of filesystem activity up to
> the point of the hang, with a ThreadClose being the last operation
> logged.
>
> There are no obvious storage and performance issues on the system.
> The AV client is disabled (and is prevented by a filter from scanning
> working copies anyway). One user left it in this state for 2-3
> hours, so we know it doesn't recover in any meaningful time frame.

For such big working copies, finishing an update can take quite a while.
But what you're seeing is definitely too long.
Sometimes the status cache can interfere, so try killing the
tsvncache.exe process if you see this happen. If the update then
finishes fast, then that's the problem.

Another reason for this can be that the timestamps on the files don't
match the pristine copy, and then svn has to do a full scan of each of
those files to get the correct status.
Unfortunately, svn 1.8 doesn't automatically adjust the timestamps on
files, and also doesn't clean up the pristine copies.
svn 1.9 however can do all this with the cleanup command. The TSVN
cleanup dialog in 1.9 has a lot more options:
* fix time stamps
* vacuum pristine copies
and some more. But these two would help fix this issue. But 1.8 doesn't
have these options :(

You could try a nightly build from trunk to test an 1.9 version of svn
and see if that would help (execute the cleanup command, then run the
update).

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3118606
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].