Results 1 to 5 of 5

Thread: Pages/Sec and Avg. Disk Queue Length

  1. #1
    Mario P. Neto Guest

    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

  2. #2
    Adam Holmes Guest

    RE: Pages/Sec and Avg. Disk Queue Length

    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


  3. #3
    Madwand Guest

    Re: Pages/Sec and Avg. Disk Queue Length

    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.


  4. #4
    Adam Holmes Guest

    Re: Pages/Sec and Avg. Disk Queue Length

    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.
    >
    >


  5. #5
    Madwand Guest

    Re: Pages/Sec and Avg. Disk Queue Length

    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.



Similar Threads

  1. Replies: 4
    Last Post: 02-07-2011, 07:28 PM
  2. How do i add pages to existing pages in iweb
    By Samsher in forum Software Development
    Replies: 3
    Last Post: 04-05-2009, 10:18 AM
  3. how to know if avg. disk queue length is too high
    By Chris in forum Windows Server Help
    Replies: 1
    Last Post: 22-10-2008, 06:50 PM
  4. Replies: 1
    Last Post: 12-04-2007, 01:32 AM
  5. High Avg. Disk Queue Length in Performance Monitor
    By Rich in forum Windows Server Help
    Replies: 1
    Last Post: 19-03-2007, 01:13 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Page generated in 1,711,624,220.30792 seconds with 17 queries