I have an trouble with Windows Server 2008 R2 Enterprise. The paged pool load memory but does not load the actual pagefile (I have space on the drive for it).
Actually the problem is in memory excesive load and I assumed that this is the problem.
Virtual memery setting :
Pagefile usability:
and the memory usage still slowly slowly grow
Task Manager performance:
Task Manager processes:
RAM map:
System information:
First comment: the display of "kernel memory - Paged", almost 22 GB here, is the virtual size of the paged pool.
The "pools" in Windows are kernel-space heap storage. They're used by kernel drivers and Windows kernel mode code in much the same way as heap is used by user mode programs, but they're in kernel address space, common to all processes, and of course, accessible from kernel mode only. There are several types of pool allocations but they break down to "nonpaged" and "paged" areas. The nonpaged pool is always resident in RAM.
The paged pool should really be called the "pageable" pool, because being called the "paged pool" doesn't mean that it is paged out of RAM, or that it necessarily will be. It does mean that it's just as subject to being paged out as are most user mode allocations.
And as with user mode allocations, we can expect that at any time, some subset of the paged pool's virtual size will be "resident" or "valid" in RAM (accessible without incurring a page fault; such RAM is considered "in use"); another subset will be "in transition" (on the standby or modified page list, and accessible but with a soft page fault), and the rest will be truly paged out - in the page file, requiring a hard page fault to access.
Now, 22 GB is a lot of paged pool. I mean, really, really a lot. Such an amount is very unusual. I suspect you have a faulty device driver that's leaking paged memory like a sieve.
I would use poolmon or Windows Performance Toolkit to find out what's allocated all of that pool. There are many answers here on SU that show how to do this in detail.
In a comment to your question, magicandre1981 linked to one of his answers that details the procedure.
Beyond that, it appears that something is preventing writing to the pagefile.
Your screen cap from RAMmap (and thank you for including that) shows that of the 19 GB of paged pool that is occupying RAM (note, this is smaller than the virtual size), about 620 MB of it is "active". Meaning that much RAM is considered to be "in use". That's the part that can be accessed without a page fault. The PTEs that describe those virtual pages have their "valid" bits set.
Almost the same amount, about 680 MB, is on the Standby page list.
And then here's the indicator of a second problem: over 17 GB are on the "Modified" list.
The "Modified" page list is where pages are put when they are moved out of a working set after having had their contents modified since they were brought in. (If a page's contents weren't modified since it was paged in, then when it's lost from its working set it's just put on the Standby page list, part of "available" RAM and immediately repurposable for other use.) Such pages cannot simply be released for use by some other process; their contents have to be saved. For pages backed by the pagefile, "saved" means "written to the pagefile".
After a modified page has been written to disk, it gets moved to the standby list, from which it can be repurposed. The standby list is counted as part of "available" RAM. (It's also part of the "Cached" counter in that task manager display.)
So you have over 17 GB of RAM on the modified page list - RAM that your system would like to write out to your pagefile.
This is wildly excessive.
Most systems have no more than a few percent of their RAM on the modified list. There are threads in the System process that are supposed to take care of writing modified pages back to disk, every time the modified list exceeds a small threshold. They're not doing the job.
I notice your current pagefile size is about 5 GB and per the WMI output it is full. (So your system is writing to the pagefile.) But it appears that pagefile expansion is, for some reason, not happening.
Hmm - you have limited your pagefile size to 20 GB maximum and even if it was expanded to that size, that would not be enough to hold its current contents plus 17 GB more. Perhaps if you made the maximum possible PF size larger (Windows suggests almost 40 GB) then things would be unstuck.
But I doubt it. I see no reason for Windows to not expand the pagefile up to the limit. True, it wouldn't hold all of the modified pages, but holding most of them is much better than keeping so many of them in RAM.
Meanwhile, those 17+ GB are not "available" for other use. This is why your "Available" RAM is so low.
We have seen bugs in pagefile size that are cleared by:
You might try that.
But your real problem is that you really shouldn't need 20 GB of paged pool in the first place. Find and fix that.
After that, you should examine your pagefile usage again and set its initial size to be at least twice as large as the routine usage. There is no good reason to set the initial size smaller than your system will routinely need. (I like to see the pagefile no more than 25% in use, for reasons having to do with the space allocation algorithms - they work a lot better with a lot of free space to work in.)
btw, both "Standby" and "Modified" pages are (somewhat misleadingly in my opinion) counted as part of "Cached" on that Task Manager screen. So the fact that you have 17.4 GB "Modified" explains that huge "Cached" number. The huge "Cached" number is not in and of itself a problem; it's one of the symptoms.
Paged pool is a categorization for kernel mode code. Kernel mode code would use paged or non-paged pool for operations and certain operation mandates certain type. This may or may not be backed by the pagefile. It is up to the Operating System to allocate and use paging. Indeed Paging costs you I/O hence OS would prefer to keep as much it can in Physical. 24 GB physical for an x64 bit OS is the config as I see. The OS can very well manage most of the operations in primary memory.
https://technet.microsoft.com/en-us/library/ff382715.aspx
The above reference will help to understand about the cached size.
I do not think this is a problem. I also cannot probably elaborate beyond what the obvious metrics in the tools, you have used, show up.
Edit:- After all the analysis "See ~40 comments" the culprit is found to be a third party driver. Analysis done with the help of the first-class analysis/indication that this is indeed a problem (credit: Jamie Hanrahan) and Paged Pool analysis (credit:Magicandre). Further analysis required to answer the actual question.
