Archived from groups: microsoft.public.win2000.general (
More info?)
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
Stubby <William.Plummer*NOSPAM*@alum.mit.edu> wrote in
news:_bSdnWhur-Z8aHbfRVn-gQ@comcast.com:
> 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 wrote:
>> 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
>>
>> "Steve Duff [MVP]" <ergodic@ergodic-systems.com> wrote in
>> news:umupoYTlFHA.3568@tk2msftngp13.phx.gbl:
>>
>>
>>>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" <me@privacy.net> wrote in message
>>>news:Xns96A3BF688A987stuartfreenews@130.133.1.4...
>>>
>>>>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.
>
Facebook
Twitter
Instagram