Page fault size

Hi,

I have a .NET service that loads a couple of hash tables on memory and acts as a cache. The service is accessed through remoting and do not use any unmanage call, only .NET object.

If I open the task manager the service is using 100Mb (this is a normal amount as the hashtable contains several entries), Virtual 111Mb but 416.220.561 page faults! The service never stops and has been running for at least 2 months without restarting.

Do you think is normal the amount of page faults I have read about the possibility of a leak but don't we have the garbage collector for .net heap

Thanks!

.NET Development31

How many page faults do the other processes show which run since the system was started. Mainly service apps like those hosted in svchost.exe. Are they significantly different How much memory is used by all processes and how much of total physical and free memory do you have Might there be a lot of page file swapping necessary

--
SvenC

Nah, not really. Windows is pretty aggressive paging out pages that haven't been touched for a while. With 111MB virtual memory, it will find plenty of candidates in your program's virtual memory. By design, hash tables do not have good locality of reference...

Thanks,

The server has 2Gb of memory and the free available never drops 500Mb. The other processes that runs all the time also has values between 20 and 40 million faults. I just want to check if there is something wrong, not many places with a decent explanation of why we have some many faults with so much memory avaialble.

Maybe as Nobugz said is a hashtable problem, but I found another interesting thing: I am checking my webservers that runs ASPNET 2 and the amount of page faults on my w3wp is quite high. As is a process that runs for a long time I thought that is the same thing but if I complete reset the process and starts again starts to fail pages like crazy when I have plenty of memory on the server (Server 2Gb, W3WP processs uses 180Mb only). I wonder if the GC has a massive page fault rate.

Thanks for any tip you may publish.

Regards