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

Large page faults issue in .net application

P: n/a
I've PerfMon-ed our application for several days now and it
consistently averages 2000 Page Faults/sec, and accumulates on average
about 4 mill page faults during 35 mins. During the same monitoring
time of 35 mins, there is never any sustained occurence of hard page
faults -as a matter of fact, almost on avg 98+ % of the entire time the
app is experiencing soft page faults. The processor rarely ever gets
over 70-80% for a sustained period of 30 sec during the entire 35 mins.
% Time in GC averages 3%.

Besides stats, we also notices that our Working Set gets consistently
trimmed every couple of minutes in the order of 20-30 MB and sometimes
even more. I also see this is directly correlated to the managed
object heap bytes being trimmed as well - exactly the same graph line
behavior. When WS gooes down, available memory goes up. I also see
that the largest number of gc collections are Gen 0s, followed by Gen
1s and the smallest Gen 2s.

We monitored a slew of other Perf counters - so if u need any other
info to help, I can supply the perf counter values readily.

QUESTION - How do I make sense of the page faults being so
excessive...? Can you supply some info and or documentation to help me
determine if this is a good, bad or expected behavior for .NET apps...?
I tried researching in lot of places but no luck to help me. Almost
every doc I find outlines that if you have hard page faults, that is a
bad thing, while soft page faults are ok.

(Sustained period = we selected 30 secs - example -> so if the
%Processor Time is over 80% for 30 secs or more we would get concerned).

Nov 17 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

<tb*********@hotmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...
I've PerfMon-ed our application for several days now and it
consistently averages 2000 Page Faults/sec, and accumulates on average
about 4 mill page faults during 35 mins. During the same monitoring
time of 35 mins, there is never any sustained occurence of hard page
faults -as a matter of fact, almost on avg 98+ % of the entire time the
app is experiencing soft page faults. The processor rarely ever gets
over 70-80% for a sustained period of 30 sec during the entire 35 mins.
% Time in GC averages 3%.

Besides stats, we also notices that our Working Set gets consistently
trimmed every couple of minutes in the order of 20-30 MB and sometimes
even more. I also see this is directly correlated to the managed
object heap bytes being trimmed as well - exactly the same graph line
behavior. When WS gooes down, available memory goes up. I also see
that the largest number of gc collections are Gen 0s, followed by Gen
1s and the smallest Gen 2s.

We monitored a slew of other Perf counters - so if u need any other
info to help, I can supply the perf counter values readily.

QUESTION - How do I make sense of the page faults being so
excessive...? Can you supply some info and or documentation to help me
determine if this is a good, bad or expected behavior for .NET apps...?
I tried researching in lot of places but no luck to help me. Almost
every doc I find outlines that if you have hard page faults, that is a
bad thing, while soft page faults are ok.

(Sustained period = we selected 30 secs - example -> so if the
%Processor Time is over 80% for 30 secs or more we would get concerned).


It largely depends on what the application is doing, but to me it looks like
you are instantiating/releasing a lot of (large) objects during this period.
The result is quite a lot of soft page faults, which is normal behavior when
reserving and committing memory from the VAS.

Willy.


Nov 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.