Molle Bestefich wrote:
> Joseph Galbraith wrote:
>> The heap manager prevents this from being true.
>>
>> Especially with lots of small allocations of varying
>> life-times, pages may never actually freed.
>>
>> Even if a page becomes unused in the heap, the heap manager
>> may not free it to the OS if it doesn't have very many free
>> pages or other thresholds aren't met.
>
> Ok, a workaround for this could be to set the heap manager's decommit
> threshold to something low, say.... 4 kilobytes for example.
>
>> And even if it did vanish from the working set, that doesn't
>> mean it was freed... only that the OS wanted the page
>> for something else.
>>
>> An interesting tidbit: last I heard, with a regular application,
>> minimizing it dumped it's entire working set.
>
> Right :-).
> Forget about the working set, then.
>
> With the workaround mentioned (lower decommit threshold), pages should
> be decommitted quickly. And once decommitted, the pages should
> disappear from the "VM Size" counter in Task Manager.
Well, unless the memory is so fragmented (various sized object
of varying lifetimes) that the pages never actually become
free... the long and short of it is that in the face of a heap
manager, you *really* can't determine anything fine grained
about the applications memory leakage by watching the OS
counters.
Now if you see a steady trending skyward, you've got a pretty
good shot that it's a memory leak... but even that may be a
really bad case of heap fragmentation (which will eventually
turn catastrophic.) Either such a trend points to a problem...
but just cause memory went up and didn't come back down... it's
real hard to draw any conclusions.
> Then there's the shared memory stuff that Stefan mentions, but luckily
> shared memory regions are excluded from "VM Size" in Task Manager.
>
> Ok, so this is the debugging options:
>
> * Muck about with the heap manager configuration. You'll get insane
> memory fragmentation (at least until you reset the setting and
> reboot), but pages will be released from TSVNCache quickly and you
> should be able to follow memory usage accurately.
>
> * Beg Stefan to implement something in TSVNCache that shows you the
> amount of heap in active use by the cache... A call to
> OutputDebugString once in a while would probably do, or a line of
> output in TSVNCache's log window at clever intervals.
Hmmm... looks to me like the only way to do this might be a
HeapWalk() ... and that might be a trifle expensive... not
sure.
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Feb 6 23:02:00 2006