Matt Doran <matt.doran_at_papercut.com> wrote:
> [Bild entfernt]
>
> Re: TSVNCache uses 100% processor time on quad-core pcs
>
> Matt Doran
>
> an:
>
> dev
>
> 02/24/2009 07:07 AM
>
> Bitte Antwort an dev
>
> Patrick Bureau wrote:
> > Hello Stefan,
> >
> > It stops when the task at hand is done.
> > The process usually never has to be manually killed as such.
> > Killing the cache and letting it restarts itself seems to help for a
> > while though.
> >
> > The main problem is that while doing an svn operation, like Update or
> > Revert for example,
> > the whole system will freeze until it's done.
> > Before, on single core pcs, it could become a bit slow but the system
> > was still quite responsive.
> >
> >
> I too see the cache process hogging CPU when performing svn operations
> (using TSVN 1.5 on XP 64). I realise the cache is monitoring file
> modifications, and these must be overwhelming the cache process. Can
> the cache process be throttled in some way when it identifies that an
> SVN operation is in progress? I guess the trick is figuring out when
> this is happening. :)
Actually, I'm quite happy when I see that sort of behavior:
TSVNCache is running at a time when all data is still present
in the Windows file cache. The point is that it should finish
processing these changes soon after the svn operation finished.
It works perfectly on my machines.
<braindump>
Things that we should have a look at:
* Do we frequently process paths more than once?
A bit of duplication would be o.k. but we should not
try to fetch status info that is bound to be invalidated
soon after.
* Can we optimize the cache implementation?
Maybe, a significant (>30%) of the runtime is spent
outside the SVN libs.
* Could notifications be processed in low-prio threads?
Requests from the Explorer would use normal prio or
even higher prio (-> no Explorer lock). TSVNCache would
then use only the spare cycles to update the status info.
Despite all of that, I would like to see some way to suspend
and resume the cache: As soon as the file cache is no longer
sufficient, the status update eats away most of the I/O cycles.
It can happen for compiler runs, for instance.
So far, I see two options to address this issue:
* Add a simple CL interface to suspend and resume the cache.
Build scripts could easily use that feature.
* Monitor disk I/O load (separate for each disk) and
accelerate / throttle down the respective monitor threads.
This is pretty hard to do but should yield the best
perceived performance.
</braindump>
Anyone willing to take that one?
-- Stefan^2.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1220586
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-02-24 13:58:59 CET