Your question is answered in your duplicate post here: http://community.kaseya.com/xsp/f/28/p/5713/27024.aspx#27024 . When setting up a monitor set, use the Paging File object, % Usage counter, _Total instance. Set your threshold to something a little above zero, and you will see whenever the system starts using more than that percent of its page file.

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: arobar

I did set it like that but it fails to report anything. I even tried setting it at zero and still no reporting

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: Leegustafson

If the monitor set is defined to only record values over/under a certain threshold, then you'll get the error message "monitor set not reporting" (or something like that) until the threashold is reached and data is recorded at least once ...

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: Lmhansen

arobar

Your question is answered in your duplicate post here: http://community.kaseya.com/xsp/f/28/p/5713/27024.aspx#27024 . When setting up a monitor set, use the Paging File object, % Usage counter, _Total instance. Set your threshold to something a little above zero, and you will see whenever the system starts using more than that percent of its page file.

That's a great answer, but not to the question that was asked.



The OP -- and I -- want to know when the amount of committed memory exceeds physical memory (as opposed to usage of page file space). It is at that point that a system must start paging heavily via physical disk I/O to the page file.



Unfortunately, the percentage of page file usage depends to a great degree on how much page file disk space is allocated -- i.e., how many and how large the page files are -- which is not always closely tied to the amount of physical RAM in the system. It is easy to allocate more or less page file space, but that will have almost zero correllation to disk I/O rate due to RAM limitation. As well, a certain portion of a page file is always in use, even in systems with plenty of RAM. "% Committed Bytes In Use" also isn't useful, as it compares the total commit charge to commit limit (which includes page file space) rather than to physical RAM.



It seems there are a whole lot of parameters that aren't of much use without complex calculations and analysis. I haven't yet found any single parameter that directly indicates when a system "goes into virtual memory". But there are two parameters which might detect when a given system needs more RAM.



The "Pages Output/sec" parameter will report when disk I/O starts to rise as a result of running short of RAM, and is probably what you really want to know anyway. It is often recommended as a good RAM metric. However, despite searching, I haven't found any numeric examples, and don't have any good alarm limits to assign to it yet. I'd really appreciates some feedback on this.



Note, this not the same as simple pages/sec or page faults/sec, which don't necessarily indicate physical paging or RAM over-commitment, and tend to give false alarms.



Another related parameter is worth considering: Disk Queue Length (average or peak) -- this is what indicates high disk load which may be due to excessive paging. Faster disk subsystems result in shorter queues and reduce the impact of high paging rates somewhat, but since even the fastest disks are so much slower than any RAM, it may not be that good an indication of actual impact of RAM paging on performance. Regardless of the cause, though, a high disk write queue is going to slow the system.



/kenw

Legacy Forum Name: Monitor Sets,
Legacy Posted By Username: Ken Wallewein