javamemorywindowsigarhyperic

Hyperic SIGAR report different swap usage on window 2012 r2

I am running Hyperic SIGAR through java on window 2012 r2. Using the Swap sigar API (http://cpansearch.perl.org/src/DOUGM/hyperic-sigar-1.6.3-src/docs/javadoc/org/hyperic/sigar/Swap.html), I am able to get the following: swap total = 5032562688, swap used = 1541095424 and swap free = 3491467264. This shows that the current swap usage is ~30%. However, checking the swap usage on Window using the counter Paging File -> % Usage in Performance Monitor as described here https://serverfault.com/questions/399855/how-much-swap-is-being-used-on-windows shows that swap usage is 0%. (% Usage Peak is also 0%). Swap usage of 0% seems to be more correct as the window server is not under much load at all. Anyone knows why SIGAR reports different / incorrect value?

Solution

  • Sigar is reporting swap using:

    ullTotalPageFile -> Swap Total

    ullAvailPageFile -> Swap Free

    ullTotalPageFile - ullAvailPageFile -> Swap Used

    http://msdn.microsoft.com/en-us/library/aa366770(VS.85).aspx

    WMI is reporting swap using:

    swapTotal -> SizeStoredInPagingFiles (Total number of kilobytes that can be stored in the operating system paging files—0 (zero) indicates that there are no paging files. Be aware that this number does not represent the actual physical size of the paging file on disk.)

    swapFree -> FreeSpaceInPagingFiles (Number, in kilobytes, that can be mapped into the operating system paging files without causing any other pages to be swapped out.) https://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx

    Problem from this is that: It looks to me that what Windows is returning to Sigar with ullTotalPageFile is a combination of all virtual and physical memory--not just virtual memory as is implied in a "Total Page File" metric. (https://communities.vmware.com/thread/354362)

    In more details: Due to the way Windows API functions report memory metrics, it is impossible to accurately retrieve swap (virtual memory) sizes as Windows reports the total commit memory which is physical memory plus swap file sizes. The only resolution that could be applied was calculatively deducting the swap sizes knowing the page and physical memory sizes.