Pages/Sec and Avg. Disk Queue Length

People,

I have HP NAS 2000 using Windows 2003 storage server with 3 GB and 2 Xeon HT
processor.
This two counters are extraordinary very high during the day, but memory and
processor is quite zero.

When you try to read or write any file you feel a very slow performance.

Anyone see this problem and know how to fix this behaviour

thanks,

Mario

If Pages/Sec is great than 150 it points to either not enough ram or
defective ram.

I'd give that a shot first as not enough ram will increase your PageFile
usage and thus your avg. disk queues.

"Mario P. Neto" wrote:

> People,
>
> I have HP NAS 2000 using Windows 2003 storage server with 3 GB and 2 Xeon HT
> processor.
> This two counters are extraordinary very high during the day, but memory and
> processor is quite zero.
>
> When you try to read or write any file you feel a very slow performance.
>
> Anyone see this problem and know how to fix this behaviour
>
> thanks,
>
> Mario

These counters show that you've got a high level of disk activity. To
an extent, that's exactly what you want on a file server. I'm sitting
at 3k or so pages/sec during a backup right now, and would love to get
it up higher, to at least 6k or more page/sec -- it was so a little
while ago, and my backup was going faster then.

So the questions for you are: What's creating that much disk activity?
Is it disproportionate to the work required? Do you need to split the
stores on to different arrays / servers so that not all users are so
hit? Etc.. Perhaps someone else can advise further on how to get
these questions addressed. Computer Management / Shared Folders / Open
Files might give you a start; an access logging tool would be better.

You are wrong about this.

Pages/sec is the number of pages read from the disk or written to the disk
to resolve memory references to pages that were not in memory at the time of
the reference. This is the sum of Pages Input/sec and Pages Output/sec. This
counter includes paging traffic on behalf of the system Cache to access file
data for applications. This is the primary counter to observe if you are
concerned about excessive memory pressure (that is, thrashing), and the
excessive paging that may result. This counter, however, also accounts for
such activity as the sequential reading of memory mapped files, whether
cached or not. The typical indication of this is when you see high number of
Memory: Pages/sec, a "normal" (average, relative to the system being
monitored) or high number of Memory: Available Bytes, and a normal or small
amount of Paging File: % Usage. In the case of a non-cached memory mapped
file, you also see normal or low cache (cache fault) activity.






"Madwand" wrote:

> These counters show that you've got a high level of disk activity. To
> an extent, that's exactly what you want on a file server. I'm sitting
> at 3k or so pages/sec during a backup right now, and would love to get
> it up higher, to at least 6k or more page/sec -- it was so a little
> while ago, and my backup was going faster then.
>
> So the questions for you are: What's creating that much disk activity?
> Is it disproportionate to the work required? Do you need to split the
> stores on to different arrays / servers so that not all users are so
> hit? Etc.. Perhaps someone else can advise further on how to get
> these questions addressed. Computer Management / Shared Folders / Open
> Files might give you a start; an access logging tool would be better.
>
>

Adam Holmes implies that high/pages per second are strongly indicative
of a memory shortage, and igores the fact that the OP mentioned that
memory usage was low. The OP wasn't entirely clear, so perhaps AH was
assuming the reverse, and so got caught up in the low-memory
page-faulting explanation.

What I'm pointing out is that a high pages/sec counter can easily arise
when there is no shortage of memory, and that can be due to file
access.

Here's a quote from
http://www.windowsitlibrary.com/Content/435/05/2.html

"NOTE: Don't automatically assume that a high Pages/sec number
indicates the existence of a memory bottleneck. An application doing a
number of disk read or write operations for data that is not currently
in the system cache (such as a database application) can also produce
high Pages/sec numbers. To determine if this is the case, also examine
the Memory object's Available Bytes figure - if it isn't
decreasing as Pages/sec is increasing, then the high Pages/sec figure
may be the result of application-generated disk I/O and not a memory
bottleneck."

I think that some of the confusion here arises because of a grammar
error in Microsoft's description of the Pages/Sec counter. Here it is:

"Pages/sec is the number of pages read from or written to disk to
resolve hard page faults. (Hard page faults occur when a process
requires code or data that is not in its working set or elsewhere in
physical memory, and must be retrieved from disk). This counter was
designed as a primary indicator of the kinds of faults that cause
system-wide delays. It is the sum of Memory: Pages Input/sec and
Memory: Pages Output/sec. It is counted in numbers of pages, so it can
be compared to other counts of pages, such as Memory: Page Faults/sec,
without conversion. It includes pages retrieved to satisfy faults in
the file system cache (usually requested by applications) non-cached
mapped memory files. This counter displays the difference between the
values observed in the last two samples, divided by the duration of the
sample interval."

The part that I say is confusing is "It includes pages retrieved to
satisfy faults in the file system cache (usually requested by
applications) non-cached mapped memory files."

Elsewhere, in the definition of Pages Input/sec, we read:

"Pages Input/sec is the number of pages read from disk to resolve hard
page faults. (Hard page faults occur when a process requires code or
data that is not in its working set or elsewhere in physical memory,
and must be retrieved from disk). This counter was designed as a
primary indicator of the kinds of faults that cause system-wide delays.
It includes pages retrieved to satisfy faults in the file system cache
(usually requested by applications) and in non-cached mapped memory
files. This counter counts numbers of pages, and can be compared to
other counts of pages, such as Memory: Page Faults/sec, without
conversion. This counter displays the difference between the values
observed in the last two samples, divided by the duration of the sample
interval."

So it's clear that they forgot the "and" in the Pages/sec definition.
If you include the "and", then it's clear that this counter includes
pages read from disk into the system file cache. This is what I meant
when I referred to "disk activity" earlier. Perhaps I wasn't clear,
but I wasn't so wrong.

Adam Holmes wrote:
> You are wrong about this.
>
> Pages/sec is the number of pages read from the disk or written to the disk
> to resolve memory references to pages that were not in memory at the time of
> the reference. This is the sum of Pages Input/sec and Pages Output/sec. This
> counter includes paging traffic on behalf of the system Cache to access file
> data for applications. This is the primary counter to observe if you are
> concerned about excessive memory pressure (that is, thrashing), and the
> excessive paging that may result. This counter, however, also accounts for
> such activity as the sequential reading of memory mapped files, whether
> cached or not. The typical indication of this is when you see high number of
> Memory: Pages/sec, a "normal" (average, relative to the system being
> monitored) or high number of Memory: Available Bytes, and a normal or small
> amount of Paging File: % Usage. In the case of a non-cached memory mapped
> file, you also see normal or low cache (cache fault) activity.