Below is what we might see in a dump file in a scenario where we have PTE depletion when we use the !vm command to get an overview of Virtual Memory Usage:
In this particular instance we can clearly see that we have a low PTE condition. In looking at the Virtual Memory Usage summary, we can see that the server is most likely using the /3GB switch, since the NonPaged Pool Maximum is only 130MB. In this scenario we would want to investigate using the USERVA switch to fine tune the memory and recover some more PTE’s, If USERVA is already in place and set to 2800, then it is time to think about scaling the environment to spread the server load. For more granular troubleshooting, where we suspect a PTE leak that we cannot explain using Performance Monitor data, we can modify the registry to enable us to track down the PTE leak. The registry value that we need to add to the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management key is as follows:
Value Name:
TrackPtes
Value Type: REG_DWORD
Value Data: 1
Radix: Hex
Once we implement this registry modification we need to reboot the system to enable the PTE Tracking. Once PTE Tracking is in place, we would need to capture a new memory dump the next time the issue occurs and analyze that dump to identify the cause of the leak.
To wrap up our post, we are going to take a quick look at a dump file of a server that is experiencing a low physical memory condition. Below is the output of the !vm command (with a couple of comments that we’ve added in)
3: kd> !vm
*** Virtual Memory Usage ***
Physical Memory: 851843 ( 3407372 Kb) <----- Server has 3.4 GB physical RAM
Page File: \??\C:\pagefile.sys
Current: 3072000Kb Free Space: 2377472Kb
Minimum: 3072000Kb Maximum: 3072000Kb
Page File: \??\D:\pagefile.sys
Current: 4193280Kb Free Space: 3502716Kb
Minimum: 4193280Kb Maximum: 4193280Kb
Page File: \??\E:\pagefile.sys
Current: 4193280Kb Free Space: 3506192Kb
Minimum: 4193280Kb Maximum: 4193280Kb
Page File: \??\F:\pagefile.sys
Current: 4193280Kb Free Space: 3454596Kb
Minimum: 4193280Kb Maximum: 4193280Kb
Page File: \??\G:\pagefile.sys
Current: 4193280Kb Free Space: 3459764Kb
Minimum: 4193280Kb Maximum: 4193280Kb
Available Pages: 1198 ( 4792 Kb) <-------- Almost no free physical memory
ResAvail Pages: 795226 ( 3180904 Kb)
Modified Pages: 787 ( 3148 Kb)
NonPagedPool Usage: 6211 ( 24844 Kb)
NonPagedPool Max: 37761 ( 151044 Kb)
PagedPool 0 Usage: 11824 ( 47296 Kb)
PagedPool 1 Usage: 895 ( 3580 Kb)
PagedPool 2 Usage: 881 ( 3524 Kb)
PagedPool 3 Usage: 916 ( 3664 Kb)
PagedPool 4 Usage: 886 ( 3544 Kb)
PagedPool Usage: 15402 ( 61608 Kb)
PagedPool Maximum: 65536 ( 262144 Kb)
Shared Commit: 771713 ( 3086852 Kb)
Special Pool: 0 ( 0 Kb)
Free System PTEs: 7214 ( 28856 Kb)
Shared Process: 7200 ( 28800 Kb)
PagedPool Commit: 15402 ( 61608 Kb)
Driver Commit: 1140 ( 4560 Kb)
Committed pages: 2161007 ( 8644028 Kb) <------ Total committed pages is 8.6GB. This amount is far larger than physical RAM, paging will be high.
Commit limit: 5777995 (23111980 Kb)
Total Private: 1363369 ( 5453476 Kb)
In this particular instance, the server simply did not have enough memory to keep up with the demands of the processes and the OS. Paged and NonPaged Pool resources are not experiencing any issues. The number of available PTE’s is somewhat lower than our target of 10,000. However, if you recall from our earlier posts, if a server is under load, the number of Free PTE’s may drop below 10,000 temporarily. In this case, as a result of the low memory condition on this server there were several threads in a WAIT state – which caused the server to hang. The solution for this particular issue was to add more physical memory to the server to ease the low physical memory condition.
And with that, we come to the end of this post. Hopefully you’ve found the information in our last few posts useful.
- Sakthi Ganesh
Share this post : |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.