我关闭虚拟内存(设置为无分页文件),删除pagefile.sys文件后,再重新设置虚拟内存,好像问题得到解决。
而且经常多次测试和搜集数据分析,我发现Windows管理控制分页文件大小的策略(或者说算法)是这样的:
开机后系统设置 (如果分页文件设置放在C盘):
分页文件初始大小 = min(自定义初始值或者系统管理时的默认初值,开机时C盘可用空间)
最大值 = min(自定义最大值或者系统管理时的默认最大值,开机时C盘可用空间)
其中,min(A,B)指A,B中的较小值。
按Windows帮助里的说明,系统管理时的默认初值 = 计算机物理内存+300MB,默认最大值 = 物理内存的3倍。
问题就出在“开机时C盘可用空间”的判断上。因为一般分页文件pagefile.sys不会自动清除(除非在安全策略里设置),开机时这个文件还存在,而且保持着上一次关机时的大小。正常的时候,开机重新设置分页文件的“可用空间”应该是C盘剩余空间加上这个上次关机保留着的分页文件本身占据的空间。但不知什么原因,系统将“可用空间”错误地认定为只是C盘剩余空间,而不计入C盘保留着的分页文件占据的空间,从而出现了我这个帖子说的问题。
比如,如果物理内存是3G,分页文件设置为“系统管理的大小”时默认初始大小是3.3G,最大值是9G。
假设开机时(也就是上一次关机时的状态)C盘剩余空间2G,上一次关机时C盘上还保留着一个4G大小的分页文件,此时设置分页文件的可用空间正常情况下应该是2G+4G=6G。按上面的算法,系统会将分页文件的初始值设置为3.3G,最大值设置为可用空间6G(而非9G)。
但如果发生异常,系统将分页文件的可用空间判定为只是C盘剩余空间的2G,因为可用空间比系统管理的默认初始最小值还小,按照算法,分页文件的实际初值和最大值都会被设置为同一个值:可用空间2G,所以就出现初始分配值偏小,而且不能增加的现象。
不但是系统管理,自定义大小的时候如果设置数值不恰当,同样会出现上述情况。
而且奇怪的是,在这种异常情况下,开机后再重新手动设置一下分页文件大小,系统又会正确判断可用空间,分配正确的最小值和最大值。
现在唯一不清楚的是,这个可用空间计算错误的低级bug是怎么产生的。关闭并重置虚拟内存倒是可以纠正这个bug。