Windows 10 Pro - Unaccounted System Commit Charge - Resource ExhaustionAsk Question

renlubo-qingdao

已于 2023-01-29 21:08:41 修改

阅读量1.1k

点赞数

文章标签： windows Powered by 金山文档

于 2023-01-12 16:16:34 首次发布

原文链接：https://superuser.com/questions/1024512/windows-10-pro-unaccounted-system-commit-charge-resource-exhaustion

版权

After idling overnight (I do not use/auto sleep or hibernate; only the display auto turns off after locking), my fully up-to-date Windows 10 Pro computer will fail to turn on the display upon mouse or keyboard activity the next day. Instead, the computer crashes and reboots. The Event Viewer shows many Error events related to low virtual memory, and Event 2004 "Resource-Exhaustion-Detector" is logged every 5 minutes for hours.

Event 2004 "Resource-Exhaustion-Detector" General

Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: sqlservr.exe (3020) consumed 343736320 bytes, svchost.exe (7036) consumed 133574656 bytes, and MsMpEng.exe (2688) consumed 110944256 bytes.

Event 2004 "Resource-Exhaustion-Detector" Details (SystemInfo only because that is where my question lies)

Event 2004 "Resource-Exhaustion-Detector" General

Event 2004 "Resource-Exhaustion-Detector" Details (SystemInfo only because that is where my question lies)

<SystemInfo> 
      <SystemCommitLimit>49033330688</SystemCommitLimit>
      <SystemCommitCharge>49031442432</SystemCommitCharge>
      <ProcessCommitCharge>1374498816</ProcessCommitCharge>
      <PagedPoolUsage>446369792</PagedPoolUsage>
      <PhysicalMemorySize>17100132352</PhysicalMemorySize>
      <PhysicalMemoryUsage>11527102464</PhysicalMemoryUsage>
      <NonPagedPoolUsage>605999104</NonPagedPoolUsage>
      <Processes>73</Processes>
</SystemInfo>

My breakdown of the above:

SystemCommitLimit = 49,033,330,688 = approx 48 GB = 16 GB RAM + 32 GB Pagefile
SystemCommitCharge = 49,031,442,432 = approx 48 GB
ProcessCommitCharge = 1,374,498,816 = approx 1.4 GB
PagedPoolUsage = 446,369,792 = approx 0.5 GB
NonPagedPoolUsage = 605,999,104 = approx 0.6 GB

If the SystemCommitCharge = 48 GB yet all processes and drivers combined have committed less than 3 GB, what has committed the other 45 GB that is causing my computer to crash?

All information that I can find regarding debugging this Event assumes that a process (ProcessCommitCharge) or a driver (PagedPoolUsage/NonPagedPoolUsage) is leaking the memory. In my case, I have no idea where to start debugging this memory leak.

Share Improve this question Follow

Sometimes memory leaks can be seen in task manager, you can add columns to the process tab if needed, watch for a program to start creeping up on memory usage. If it is a svhost,exe entry chewing memory, right click on it and select go to services, it will highlight all the services running under that particular instance of svhost.exe

– Moab

Jan 11, 2016 at 0:59

SQLServer (except for the Developer and Express editions) preallocate a large memory footprint at start, so are you sure you have configured it to leave a little ram free for the OS? Of the processes you list, it is certianly suspect. If you look at it in Process explorer, do you get any hints as to where the issue lies?

– Frank Thomas

Jan 11, 2016 at 3:25

This issue appears to only occur when the machine is locked and idle, so I have not been able to catch it "in the act" using Task Manager or Process Explorer. I've installed SQL Server Dev 2014, and it consistently has a 374 MB Commit Size with a 72 MB Working Set (this is a fresh install w/o databases yet). My assumption is that applications should increase ProcessCommitCharge and drivers should increase Paged/NonPagedPoolUsage, yet 45 GB of SystemCommitChage is unaccountable, and I'm stumped. My one hunch is that this has something to do with Windows Hello (Surface Pro 4 infrared camera).

– Dan Terry

Jan 12, 2016 at 4:20

@DanTerry, I'm seeing the same symptoms - did you ever get confirmation on root cause and/or a solution for this?

– Scott Jones

Jul 8, 2020 at 23:43

@ScottJones, This issue was occurring with a Surface Pro 4 that had significant sleep and power management issues because it was an early adopter of Connected Standby using Intel Skylake (the first x86 chip to offer Connected Standby AFAIK). I gave up trying to debug the issue (I configured the computer to allow auto-sleep) before this question had any answers, so I don't know if the answer below would have solved my issue.

– Dan Terry

Jul 11, 2020 at 3:05

Answer

I'm running Windows 10, but I had the exact same issue. Lots of physical memory (16GB), most of which was free, but a huge committed memory (25GB) that eventually triggered Out Of Memory errors. To resolve it:

Grab Sysinternals Process Explorer.

Run as Administrator.

Add the column Page Faults and sort by that.

In my case the top entry was RunSwUSB and it had something like 13 million entries!

I stopped that service and you can see the results immediately in the graph below.

事情的背景和这个博客主的情况有点像，

启动程序，运行自动化测试一段时间，一般是过一夜，第二天报内存不足，但是占用内存最大的程序并没有突然增大或者缓缓变大，系统的提交的内存和系统的内存限制接近，但是进程提交的内存和驱动提交的内存量之和离系统设置的界限还好几个G，一般都超过了10G

原来以为是自己编写的程序有内存泄漏，但是后来根据数据分析，找到了这篇文章，觉得可能是系统的某个驱动有问题造成的

后面找到原因再更新结果

最近一段时间发现业务流程的一台设备windos2008的可以使用内存不断减少，今日早已降到2G。

测算了跑着进度的内存和，发现与事实不符（不清楚那剩下的4G跑哪去了）

之后用了RAMMap v1.51展开分析内存，下载链接，请点击此处

剖析发现

Mapped file占用很多内存4G,依据微软官网给的表述：

You experience performance issues in applications and services in various versions of Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. Additionally, you notice the following symptoms:

1）Available memory is almost exhausted.

2）The system file cache consumes most of the physical RAM.

3）There is a continuous and high volume of cached read requests to the hard disk.

If there is a continuous and high volume of cached read requests from any process or from any driver, the working set size of the system file cache will grow to meet this demand. The system file cache consumes the physical RAM. Therefore, sufficient amounts of physical RAM are not available for other processes

换句话说文件系统的缓存文件没做限定造成，不断增加文件系统的缓存文件不断占有物理学内存。

解决方法:

官方网给予解决方案是干内存限制（不可以占有的内存不断增加）

组装Windows Dynamic Cache Service，下载链接点击此处

注册服务

Dynamic Cache Registry settings，在这里我设置权限10G（物理学内存12G）

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters]

"MaxSystemCacheMBytes"=dword:00002800

"MinSystemCacheMBytes"=dword:00000064

"SampleIntervalSecs"=dword:0000003c

"CacheUpdateThresholdMBytes"=dword:00000064

仅需设定MaxSystemCacheMBytes，这儿设为10G

在服务上运行Dynamic Cache服务。留意：必须重新启动运用。

You experience performance issues in applications and services when the system file cache consumes most of the physical RAM

Microsoft Windows XP Professional x64 Edition Windows Vista Home Basic More...

Symptoms

Available memory is almost exhausted.

The system file cache consumes most of the physical RAM.

There is a continuous and high volume of cached read requests to the hard disk.

Cause

Memory management in Microsoft Windows operating systems uses a demand-based algorithm. If any process requests and uses a large amount of memory, the size of the working set (the number of memory pages in the physical RAM) of the process increases. If these requests are continuous and unchecked, the working set of the process will grow to consume all the physical RAM. In this situation, the working sets for all the other processes are paged out to the hard disk. This behavior decreases the performance of applications and services because the memory pages are continuously written to the hard disk and read from the hard disk.

This behavior also applies to the working set of the system file cache. If there is a continuous and high volume of cached read requests from any process or from any driver, the working set size of the system file cache will grow to meet this demand. The system file cache consumes the physical RAM. Therefore, sufficient amounts of physical RAM are not available for other processes.

On 32-bit versions of Microsoft Windows operating systems earlier than Windows Vista, the working sets of the system file cache have a theoretical memory limit of less than 1 gigabyte (GB). The limitation of the virtual address range prevents the working sets of the system file cache from exhausting the physical RAM.

On 32-bit versions of Windows Vista operating systems, kernel resources are allocated dynamically. The working set of the system file cache increases to consume the virtual address range of the kernel mode at the expense of other kernel resources. The limitation of this memory range is less than 2 GB. If the computer has more than 2 GB of physical RAM, the cache cannot exhaust all the physical RAM. However, the cache can exhaust the virtual address space in the kernel. This can cause allocation failures for other kernel components.

On 64-bit versions of Windows operating systems, the size of the virtual address range is typically larger than the physical RAM. In this situation, the working set for the system file cache can increase to consume most of the physical RAM.

Resolution

The memory management algorithms in Windows 7 and Windows Server 2008 R2 operating systems were updated to address many file caching problems that were found in earlier versions of Windows. There are only certain unique situations in which you have to implement this service on computers that are running Windows 7 or Windows Server 2008 R2.

How to determine whether your system is affected

To determine whether your system is affected by this issue, install the SysInternals RamMap tool. You can obtain the tool from the following Windows Sysinternals website:

http://technet.microsoft.com/en-us/sysinternals/ff700229

When you run the tool, select the Use Counts option. This displays several columns that show the current pattern of memory usage. Click the Active column to sort by the number of bytes used, and note the top usage directly under the total.

If the top use count is “Metafile,” and if a large part of available memory is being used, you are experiencing the System File Cache issue that is described in the "Symptoms" section. You can verify this by using Performance Monitor to monitor the Memory\System Cache Resident Bytes counter and see the cache grow continuously over time.

Figure 1. Example RamMap output in which the computer is experiencing the issue.

Figure 2. Example RamMap output in which the computer is not experiencing the issue.

If the Memory\System Cache Resident Bytes counter in Performance Monitor shows an upward trend over time, the computer is experiencing the issue, as shown in Figure 3.

Figure 3. Example Performance Monitor output in which the computer experiences the issue over time

Restart requirements

You do not have to restart the computer when you install, uninstall, or use this service.

If you are you reading this article because you are working with a customer who believes that they are affected by this issue, follow these steps to help resolve the issue.

Verify that the customer's RamMap output, perfmon, or poolmon data confirms that the System File Cache is consuming most of the physical RAM, as described earlier.

To obtain the Windows Dynamic Cache Service, download it here.

Some Dynamic Cache Registry settings are as follows:

File servers, you might want to try 1GB.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters]
"MaxSystemCacheMBytes"=dword:00000400
"MinSystemCacheMBytes"=dword:00000064
"SampleIntervalSecs"=dword:0000003c
"CacheUpdateThresholdMBytes"=dword:00000064

Exchange 2007, you might want to try 500 MB:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters]
"MaxSystemCacheMBytes"=dword:000001F4
"MinSystemCacheMBytes"=dword:00000064
"SampleIntervalSecs"=dword:0000003c
"CacheUpdateThresholdMBytes"=dword:00000064

SQL 2005 and higher, in the past when working with SQL EE’s, have used 2GB:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters]
"MaxSystemCacheMBytes"=dword:000007D0
"MinSystemCacheMBytes"=dword:00000064
"SampleIntervalSecs"=dword:0000003c
"CacheUpdateThresholdMBytes"=dword:00000064

More Information

To work around this issue, use the GetSystemFileCacheSize API function and the SetSystemFileCacheSize API function to set the maximum or minimum size value for the working sets of the system file cache. The use of these functions is the only supported method to restrict the consumption of physical memory by the system file cache.

The Microsoft Windows Dynamic Cache Service is a sample service that demonstrates one strategy to use these APIs to minimize the effects of this issue.

Installing and using the Microsoft Dynamic Cache Service does not cause the exclusion of support for Microsoft Windows. This service and its source code are provided as an example of how to use the Microsoft supported APIs to reduce the growth of the file system cache.

You can obtain the service and source code from the following Microsoft website:

http://www.microsoft.com/download/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en

Additional Resources

Read Chapters 9 (Memory Management) and 10 (Cache Manager) of Windows Internals, the 5th Edition.

MEMORY MANAGEMENT (LARGE SYSTEM CACHE ISSUES) Blog Post

Slow Large File Copy Issues Blog Post

Memory Limits for Windows Releases

976618 You experience performance issues in applications and services when the system file cache consumes most of the physical RAM

918483 How to reduce paging of buffer pool memory in the 64-bit version of SQL Server

895932 Things to consider before you enable System cache mode in Windows XP

232271 How to Optimize Windows NT Server Using the Registry

837331 About Cache Manager in Windows Server 2003

http://technet2.microsoft.com/windowsserver/en/library/EFA621BD-A031-4461-9E72-59197A7507B61033.mspx

LargeSystemCache TechNet Topic

RamMap Blog Post

排查缓存和内存管理器性能问题

项目

2022/12/22

7 个参与者

反馈

在Windows Server 2012之前，两个主要潜在问题会导致系统文件缓存增长，直到某些工作负荷下可用内存几乎耗尽。当这种情况导致系统缓慢时，可以确定服务器是否面临其中一个问题。

要监视的计数器

内存\长期平均备用缓存生存期 (s) < 1800 秒

内存\可用 Mbytes 低

Memory\System Cache Resident Bytes

如果内存\可用 Mbytes 较低且同时内存\系统缓存驻留字节消耗物理内存的很大一部分，则可以使用 RAMMAP 来了解缓存的用途。

系统文件缓存包含 NTFS 图元文件数据结构

此问题由 RAMMAP 输出中的大量活动图元文件页指示，如下图所示。此问题可能在繁忙的服务器上观察到，访问了数百万个文件，从而导致缓存 NTFS 图元文件数据未从缓存中释放。

DynCache 工具用于缓解的问题。在 Windows Server 2012+ 中，体系结构已经过重新设计，此问题不应再存在。

系统文件缓存包含内存映射文件

此问题由 RAMMAP 输出中的大量活动映射文件页指示。这通常表示服务器上的某些应用程序使用 CreateFile API 打开大量大型文件，并设置了FILE_FLAG_RANDOM_ACCESS标志。

知识库文章 2549369详细介绍了此问题。 FILE_FLAG_RANDOM_ACCESS标志是缓存管理器在内存中保留文件映射视图的提示，只要 (，内存管理器才会发出内存不足) 信号。同时，此标志指示缓存管理器禁用文件数据的预提取。

通过Windows Server 2012+ 中的工作集修整改进，这一情况已得到一定程度的缓解，但应用程序供应商无需使用FILE_FLAG_RANDOM_ACCESS来主要解决该问题本身。应用供应商的替代解决方案可能是在访问文件时使用内存优先级低。这可以使用 SetThreadInformation API 来实现。从工作集中更主动地删除以低内存优先级访问的页面。

缓存管理器，从Windows Server 2016开始，通过在做出剪裁决策时忽略FILE_FLAG_RANDOM_ACCESS来进一步缓解此问题，因此，在未打开FILE_FLAG_RANDOM_ACCESS标志的情况下，缓存管理器仍会遵循此 (标志来禁用文件数据预提取) 。如果已使用此标志打开大量文件，并且以真正随机的方式访问，仍可能导致系统缓存膨胀。强烈建议应用程序不使用FILE_FLAG_RANDOM_ACCESS。

远程文件脏页阈值一直超过

如果系统在从远程客户端写入期间偶尔出现速度变慢，则表示此问题。将大量数据从快速远程客户端写入到慢速服务器目标时，可能会出现此问题。

在Windows Server 2016之前，在这种情况下，如果缓存中的脏页阈值达到，则进一步写入的行为就像存在写入一样。这可能会导致大量数据刷新到磁盘，如果存储速度缓慢，可能会导致长时间延迟，从而导致远程连接超时。

在 Window Server 2016 和转发中，将实施缓解措施以减少超时的可能性。实现远程写入的单独脏页阈值，超出内联刷新时将执行内联刷新。这可能会导致在大量写入活动期间偶尔出现减速，但在大多数情况下会消除超时的风险。默认情况下，此远程脏页阈值为每个文件 5 GB 。对于某些配置和工作负荷，不同的数字性能会更好。

可以使用以下 regkey 控制此阈值：HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\RemoteFileDirtyPageThreshold。如果默认大小 5 GB 对配置不起作用，建议尝试以 256-MB 增量增加限制，直到性能令人满意为止。请注意以下事项：

需要重新启动才能使此 regkey 的更改生效。

RemoteFileDirtyPageThreshold 的单位是页面大小由缓存管理器) 管理的页数 (。这意味着它应设置为所需的大小（以字节为单位）除以 4096。

建议的值为 128MB <= N <= 50% 的可用内存。

通过将阈值设置为 -1，可以完全禁用此阈值。不建议这样做，因为它可能会导致远程连接超时。

LargeSystemCache

Article

10/08/2009

2 minutes to read

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

LargeSystemCache

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Data type	Range	Default value
REG_DWORD	0 \| 1	Windows XP Professional: 0 Windows Server 2003: 1

Description

Specifies whether the system maintains a standard size or a large size file system cache, and influences how often the system writes changed pages to disk.

Increasing the size of the file system cache generally improves server performance, but it reduces the physical memory space available to applications and services. Similarly, writing system data less frequently minimizes use of the disk subsystem, but the changed pages occupy memory that might otherwise be used by applications.

Value	Meaning
0	Establishes a standard size file-system cache of approximately 8 MB. The system allows changed pages to remain in physical memory until the number of available pages drops to approximately 1,000. This setting is recommended for servers running applications that do their own memory caching, such as Microsoft SQL Server, and for applications that perform best with ample memory, such as Internet Information Services (IIS).
1	Establishes a large system cache working set that can expand to physical memory, minus 4 MB, if needed. The system allows changed pages to remain in physical memory until the number of available pages drops to approximately 250. This setting is recommended for most computers running Windows Server 2003 on large networks.

This entry and the Size entry (which is in the HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters subkey) store the setting of the Optimization section of the Server Optimization tab in Network and Dial-up Connections.

Option setting	Large System Cache value	Size value
Minimize memory used	0	1
Balance	0	2
Maximize data throughput for file sharing	1	3
Maximize data throughput for network applications	0	3

Change Method

To change the value of this entry on Windows Server 2003, use the Server Optimization tab in Network and Dial-up Connections. Right-click My Network Places, click Properties, right-click Local Area Connection, click Properties, click File and Printer Sharing for Microsoft Networks, and then click the Properties button. To set the value of this entry to 0, select the Maximize data throughput for network applications option. To set the value to 1, select Maximize data throughput for file sharing.

Note

Because setting the value of this entry to 1 is not recommended for computers running Windows XP Professional, you cannot use Network and Dial-up Connections in Windows XP Professional to change the value of this entry.

The Windows Server 2003 default value (1) is designed for file servers. Because this value can degrade service performance, it is not recommended for application servers. If you are running an application server, change the value of this entry to 0 by selecting the Maximize data throughput for network applications option in Network and Dial-up Connections.

The system sets the value of this entry to 1 when you install Windows Server 2003. But many applications, such as SQL Server and Microsoft Exchange, change the value of this entry to 0.