This would match well with what I'm seeing. I have a nightly build
that deletes 15,000 directories or so and recreates them. Every
morning when I come in TSVNCache.exe has jumped up in memory usage
from the previous night. I haven't had a chance to test it with a
nightly, but hope to do so at a safer time next week.
-Jody
On 2/7/06, Peter McNab <mcnab_p@melbpc.org.au> wrote:
> Stefan Küng wrote:
> > Peter McNab wrote:
> >
> >> TortoiseSVN 1.4.0, Build 5629 - 32 Bit -dev & Subversion 1.3.0,
> >> Win2K dual core CPU box.
> >>
> >> Explore to drive with revisioned folder.
> >> TSVNCache crawls.
> >> Memory usage climbs as expected.
> >> Browse back to MyComputer view.
> >>
> >> Repeat above process to the same drive as before.
> >> Memory usage climbs some more.
> >>
> >> Repeat above process to the same drive as before.
> >> Memory usage climbs some more.
> >>
> >> Select whitespace in WC.
> >> Press F5 .
> >>
> >> Repeat above process to the same drive as before.
> >> Memory usage does not climb this time.
> >
> > If the memory use doesn't climb too much, then I guess that additional
> > memory used is due to some more directories added to the cache (due to
> > change notifications).
> >
> >> Did some testing using a USB removable drive, marvelous thing really.
> >>
> >> Connected drive and Windows autorun feature pops up an explorer view
> >> of first partition.
> >> Selecting and moving Explorer vertical scrollbar prompts TSVNCache to
> >> crawl newly revealed folders.
> >> In TaskManager the cache memory usage climbs a bit.
> >> Use windows "Unplug" process and note that cache memory usage does
> >> not decrease as indicated by TaskManager.
> >>
> >> Repeat above process.
> >> Memory usage climbs some more but not a lot in % terms.
> >>
> >> Repeat above process
> >> Memory usage climbs some more but not a lot in % terms.
> >>
> >> Copy a WC onto the USB drive.
> >> Memory usage climbs some more but not a lot in % terms.
> >> Delete WC. (7000+ files, 1300+ Folders)
> >> Memory usage indicated in TaskManager does not decrease.
> >
> > I've seen that too. But that's expected: Windows doesn't really free
> > memory which a process frees, it waits until there's no more memory
> > available for other processes or if windows is idle. That's because
> > reallocating/freeing memory takes some time (windows has to move
> > around memory blocks for that).
> >
> >> Memory allocated did not rise above 19MB.
> >> There still appears to be a small, but less threatening leak still
> >> occurring. Sorry I cannot be more specific.
> >
> > I've added a tooltip for the trayicon in revision 5641 which shows the
> > number of cached directories. Maybe that helps to find out where/if
> > there's a memory leak.
> >
> Excellent, better idea than mine too.
>
> OK. Did some more testing with r5644 and the tooltip with interesting
> results.
>
> After a re-boot the cache crawls to completion and I see it showing 3250
> Cached Directories.
> Explorer has not been opened at this point.
> TSVNCache memory used as shown by Process Explorer was sitting at 11728k.
> TSVNCacheWindow shows no further crawling activity from this point on.
> To stimulate some disk activity, run ClamAv on C: drive only, which
> contains predominantly Windows installed files, (D: gets everything
> else, TortoiseSVN included, E: contains active WCs and lots of non
> revisioned stuff).
>
> ClamAV runs to completion and pronounces it checked 2152 directories
> with just a handful it couldn't open.
> Meanwhile, Process Explorer now shows TSVNCache is using approx 50Mb memory.
> ToolTip tells us Cached Directories 94635.
> TSVNCacheWindow has not crawled during the ClamAV activity but is still
> responsive as shown when open Explorer and navigate.
>
> One conjecture I have is that maybe compressed files are being opened
> into a temporary folder for scanning by ClamAV but the entries are not
> being removed from the cache when the temp file/folder is destroyed.
>
> Anyway, something for you to mull over.
> ClamAV is an open source antivirus project on SourceForge for those who
> did not know.
>
> Rgds
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 7 17:43:16 2006