Question about paging rate

[Stuart Rogers]

I run an application which I feel is paging too much. The PC is dedicated
to this one application and mysql. The app in question page faults at a
rate of between 30--70/second averaging around 55/second, however the
system pages/second is less than 0.1/second so these faults are not causing
hard page faults. Should I be concerned about this, it seems to me that
since this is the only app or service with any apreciable paging that this
could be a design problem within the app itself. However I have been unable
to find out what is actually causing the page faults. Can any one suggest a
way to trace the actual storage causing the fault I could then try and find
out what this memory is used for within the app.

Stuart

 

[Steve Duff [MVP]]

A request for new virtual address space or a fresh data page
will generate what is termed a demand-zero fault. This takes
a page of memory and zeros it for the application to use.
While technically a fault (because it is initiated by a reference to
non-existant memory in the app's address space), it does not in and of itself
produce disk activity - at least until and if it is paged out.

An application that is doing this and continuously growing in
virtual address size is the classic "memory leak" (or just badly
written). If it is doing this and not growing endlessly then it may
be doing process-shared memory or deallocations/reallocations
or using AWE or one of the dozens of other possible memory
management strategies.

Another source of soft faults is when a page is moved back
from the standby list (on its way out the door so to speak), back
in to the application's memory working set. This is just
a page mapping operation and no disk activity is generated.
These are so-called transition faults and the rate is really
dependent on what else is running on the server (especially
SQL Server and Exchange which both have quite highly
specialized internal memory mangement of their own.)

Also, file operations are usually through virtual memory section
mappings internally in the o/s, and so the fault rate counts these
cache misses. Again this is not an indication of an application
problem, it is just the system doing what it is supposed to. If your
application is file-intensive (say a database app), this may be
the source.

And if the app needs to run with "lock pages in physical memory"
rights it is probably safe to assume it knows what it is doing. You
can use perfmon to see some of the VM indicators, though some
things like AWE, shared and large pages are not counted in
some of the indicators.

The best thing to do of course is ask the developers.

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.

 

[Stuart Rogers]

None of the memory indicators for this app are increasing so there does
not appear to be a memory leak. The Cache values are pretty static as
well

It is not a database app either, however it does manipulate quite a lot
of data and files, it collects data from a weather station. So I guess it
is probably the OS doing its thing with data going to disk for these
files.

One thing I do know about this app is that it is coded using Delphi so I
dont know if that is likely to cause it to behave differently with
regards to memory and paging?

Stuart

 

[Stubby]

How much physical RAM do you have? Maybe you could improve things by
adding more, say, doubling it? Note that the paging rate you mention is
within a factor of 2 of what a typical disk can do. 7200 RPM is 120 RPS
so that is approximately the max number of blocks per second you can
get. (Yah, I know sometimes you can pick up more than one block per rev.)

 

[Stuart Rogers]

These are not hard page faults, they do not for the vast majority end up
with and I/O to the page file so a different h/drive will fix noting in
this case.

Stuart