对于32位Windows,boot.ini中的“ / 3Gb”开关是否有任何缺点?


8

Microsoft建议在Boot.ini中使用/ 3Gb开关,以便为在32位系统上运行的进程获取更多的内存。

当前,我需要大量的内存来进行devenv过程(Visual Studio 2008),因为我有一个复杂的解决方案,其中包含很多项目和表单,并且在设计时会消耗大量资源。

我想问一下,如果有人知道,使用/ 3Gb交换机的负面影响是什么,在任何情况下都不建议使用它。


感谢所有回答,所有帖子都非常有用,有很多注意事项。我还阅读了一些文档,并注意到对于MS SQL Server,即使对于32位系统,您也
不需要这样做

Answers:


11

在台式机上,可能没有问题。在带有/ 3GB开关集的W2K3 / WXP计算机上,内核页面缓冲池较小。对于台式机来说,这可能不是问题,因为您不应该接近耗尽内核页面缓冲池。在服务器上,耗尽内核页面缓冲池将导致您遇到问题,并且更有可能耗尽它。

这是有关与/ 3GB开关相关的内核内存注意事项的一些详细信息。如果确实需要,您可以启动NT内核调试器并在更改之前和之后通过以下文档中的信息对系统进行配置文件:http : //blogs.technet.com/markrussinovich/archive/2009/03/26 /3211216.aspx


3
我总是想知道,当我投票时,为什么要投票。我不认为此发布中的任何内容实际上是不正确的,但是如果是这样,我想知道,以便我可以删除该帖子或对其进行更正。我很好奇下降投票者所面临的问题……(当然,我意识到他们永远也不会回来回应这一评论……哦,好吧……)
Evan Anderson

5

您的内核可用的内存将更少-交换机将内核模式地址空间/用户模式地址空间的分配从2GB调整为2GB,将1GB调整为3GB。在继续之前,请阅读Raymond Chen在/ 3GB上的帖子以及后续内容。


5

进行任何更改之前,您应该首先检查要运行的进程是否与LARGEADDRESSAWARE标志链接。使用该标志,进程使用内存的方式将保持不变。

您可以为此使用SDK工具:

dumpbin / headers exeName

标出的标题应包括:

应用程序可以处理大(> 2GB)地址

我在devenv.exe上进行了检查,在VS2008中确实包含了该标志。


4

缺点很多。默认情况下,Windows将为每个进程分配一个4GB的内存池,该内存池在内核模式进程(对所有应用程序通用)和用户模式进程(对每个应用程序唯一)之间分配50/50(简化的说明)。因此,在系统上运行的应用程序具有2GB的内存可玩,而系统本身具有2GB的内存。重要说明:第二个2GB与系统上运行的所有应用程序的2GB相同。

/ 3GB开关调整拆分,以使内核模式获得1GB,用户模式获得3GB。

现在考虑您正在运行的应用程序。其中一些将需要更多的内核模式空间,而另一些将需要更多的用户模式空间。由于内核模式池是共享的,因此如果您正在运行使内核模式内存承受压力的应用程序,则会很快耗尽那里的内存。另一方面,如果您的应用程序使用大量用户模式内存,则实现/ 3GB可以为它们提供所需的余量。

因此,这实际上取决于您要运行的应用程序的性质。黄金法则是咨询应用程序供应商并阅读文档。特别是如果应用程序供应商没有建议,您应该开始变得可疑...他们是否正确测试了他们的应用程序?这是每个供应商都应该知道的基本知识。

这里有一个很好的讨论:http : //blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

在您的特定情况下,我认为切换到64位并获得更多的RAM将是一个更可行的解决方案,因为/ 3GB并不能真正满足您的需求(甚至可以在XP上使用吗?)


我认为,与其说“内核模式池”,不如说“内核虚拟地址空间”。对我来说,“共享”也意味着“对所有应用程序都相同”。是这样吗?
dma_k 2012年

1

我们已经在几个运行大量大图像的图像处理应用程序的系统上使用了它,但从未发现任何问题。在需要额外的应用程序内存Gig的任何情况下,您可能都会让该应用程序运行,而不会对系统做任何其他事情,因此不会产生太大影响。



1

对于LARGEADDRESSAWARE二进制文件,它只能在企业服务器操作系统上可靠地运行(调试驱动程序等除外)。

devenv不是这样的二进制文件。例如,SQL Server和Exchange。

您需要使用x64位OS VS x64编辑:在x64检测到LARGEADDRESSAWARE可以突破2GB的限制。


actaully devenv.exe是bigaddressaware。
杰克·博灵

正确,我在编辑x64时错过了它。再次编辑
-gbn
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.