Why my memory: pages/sec so high

Question:

We have been having issues daily at 2:30am with our SQL server. I am still
trying to get a clear understanding with the DBA team about what is going on
at this time, but from an IT perspective, I started running perfmon last
night and caught some high pages/sec activity. Around 2:24am, pages/sec
went to 3290, reaching a high of 4404 at the time SQL shut down (it
restarted a minute later). From my readings online, it looks like this
isn't necessarily an indication of a lack of memory on the system, so I need
to add additional monitors to determine what is. So I've added a physical
disk monitor for sec/transfer on the paging disk, as well as memory/%
committed bytes. Are there other monitors I should set up? Also, are these
pages/sec readings completely insanely high or what? From what I've read,
it is.

 

Answer 1:

http://dbaspot.com/forums/sqlserver-server/428551-high-memory-pages-sec.html

This sounds like another process such as an SSIS package is running at
2:30AM and requesting a ton of memory which is leading to the very high
paging. I wouldn't worry too much about disk counters a much as I would
about finding what is running at that time. Check SQL Agent or any other
schedulers for jobs set to run at that time. Also look at the perfmon
counters for processes that start near then and use a lot of memory.

Answer 2:

http://www.sql-server-performance.com/faq/high_pages_sec_counter_p1.aspx

 

Normal Causes of High Paging Rates

• When a computer is first booted.
• When an application is first started, or exited.
• When data is loaded into an application, or saved from an application to disk.
• When a file is being written to a disk, or copied off of a disk.
• When backups are being made or restored.

Answer 3:

http://support.microsoft.com/kb/139609

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.

As seen from the above information, a high number of Memory: Pages/sec is not necessarily indicative of memory pressure or a Performance Monitor reporting error. It is necessary to monitor other counters, such as those mentioned above, to get the complete picture of what is happening in your particular case.