By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,395 Members | 2,505 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,395 IT Pros & Developers. It's quick & easy.

ASP Website - Is 2,464,794,919 Page Faults Excessive?

P: n/a
Hi

Have 4Gb of RAM and plenty of free disk.

Those page faults are for DLLHOST.EXE using ~370Mb RAM. inetinfo.exe has
403,106,036 page faults at the time of writing and is using ~145Mb RAM.

Why so many page faults. System uptime ~500 hours.

The ASP-based site does interface with a SQL Server instance on a completely
separate PC via a dedicated 1Gbit connection.

Regards

David
Jun 8 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
"David Morgan" wrote ...
Those page faults are for DLLHOST.EXE using ~370Mb RAM. inetinfo.exe has
403,106,036 page faults at the time of writing and is using ~145Mb RAM.

Why so many page faults. System uptime ~500 hours.

The ASP-based site does interface with a SQL Server instance on a
completely separate PC via a dedicated 1Gbit connection.


Hi David,

I'm no expert on that - but I found this...

"Computername\Process\Page Faults/sec.: Inetinfo - This counter tracks the
number of times the server has to page pieces of inetinfo.exe to disk per
second. You want this number as small as possible."
http://support.microsoft.com/default...;en-us;q305313

So - yes, sounds a bit excessive huh...

Regards

Rob
Jun 9 '06 #2

P: n/a

"David Morgan" <mi*************************@davidmorgan.me.uk> wrote in
message news:ub**************@TK2MSFTNGP04.phx.gbl...
Hi

Have 4Gb of RAM and plenty of free disk.

Those page faults are for DLLHOST.EXE using ~370Mb RAM. inetinfo.exe has
403,106,036 page faults at the time of writing and is using ~145Mb RAM.

Why so many page faults. System uptime ~500 hours.

The ASP-based site does interface with a SQL Server instance on a completely separate PC via a dedicated 1Gbit connection.

Regards

David


Even with large amounts of RAM available the OS will keep the number of
pages in a process workset to a moderate figure. Use Task manger to see the
size of the working set, also enable the column for virtual memory size.

When a page is needed by the process (one which may be in it's allocated
virtual memory) and not in it's working set a page fault occurs. The vast
majority of these faults will be 'soft' faults, that is the page is actually
in physical memory and merely needs to be marked as being in the process
working set. The system can generate vast quantities of page faults without
there appearing to be a problem.

However in this case that is still 1370 faults a second. This would
indicate that the workset is being kept too small. With that rate of
faulting the OS ought to grow the working set to bring the faulting rate
down. Factors that can limit the ability of the OS to do this would be the
number of other processes running and their working set requirements.

Anthony.
Jun 9 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.