操作系统 /3GB /PAE 参数详解

问题描述：

在 Windows®32 位系统上，当Domino® 服务器负载很大或者运行很复杂的应用程序时，可能会由于占用内存太多而意外宕机。具体的说，某个特定的进程占用的内存可能会达到用户地址空间的上限。在默认状况下，Windows 32位系统上用户地址空间是 2 GB。在 Domino 服务器负载过大时，进程占用的内存可能很快就达到了上限。

原因：

所有的32位应用程序都有4GB的用户地址空间上限，因为32位地址最多可以映射4 GB的内存。不管增加多少物理内存，CPU或磁盘都无法克服这个限制。
在不同的操作系统上，如何将4 GB的地址空间分给用户模式（也称用户地址空间）也有不同的规范。在Windows 32位操作系统上这样进行地址空间的分配：默认情况下，用户地址空间是2 GB，其余的2 GB预留给操作系统内核。

随着复杂的企业级应用对内存需求的增加，2GB的用户地址空间很快就会被占满，导致错误或宕机。当多个企业级组件在一个进程中运行这种情况下，如 Domino，Oracle，和Java® ，更容易出现这种情况。根据需要，在这样的环境里，对于某些版本的 Windows 操作系统，可以修改 boot.ini 加入 /3GB 参数，从而将可提供给进程的用户地址空间增加到3 GB。

/3GB 参数起什么作用？
正如上文提到的那样，在Windows 32位操作系统中，默认用户地址空间大小是2 GB，其余的2 GB预留给系统内核，总共是4 GB。实际上，你可以这样认为：所有的进程（在内核模式下执行时）都共享着相同的内核地址空间，大小为2 GB。大多数情况下，用户地址空间都是由每个进程独立使用的，除非进程选择分配可共享的内存空间。

在某些 Windows 32 位操作系统上，可以在 boot.ini 加入 /3GB 参数来改变虚拟地址空间默认的百分比。加入 /3GB 参数后，虚拟地址空间的划分规则发生了改变，用户地址空间增加至3 GB，内核地址空间减少至1 GB。这个参数没有改变整体的虚拟地址空间大小（进程可寻址空间总共还只有4 GB），并且对于操作系统如何管理虚拟内存也不会有影响。/3GB 参数只是简单的将每个进程的用户地址空间和内核地址空间进行了重新分配。

下列兼容 /3GB 参数的Windows 32位操作系统版本信息，摘自微软技术文档“内存支持与Windows操作系统”：
支持 /3GB参数的Windows 32位操作系统版本
Windows NT 4.0 Enterprise Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows 2003 Server
Windows 2003 Enterprise Server
Windows 2003 Datacenter Server
Windows XP Professional
当使用这个参数时，必须综合考虑关于应用层（Domino）和内核层（操作系统）的一些潜在问题：
/3GB 参数会发挥一定作用；然而，即使启用这个内核层面的设置，32位进程还是无法使用超过2 GB的用户地址空间，除非编译时加入了 /LARGEADDRESSAWARE 参数。在编译32位可执行程序时必须指定这个参数。

如果系统内核配置了 /3GB 参数，而在编译可执行程序(.exe)时又未使用Large Address Aware 选项，那么每个进程可寻址的用户地址空间上限依然是2GB。逻辑正好相反，这多出来的1 GB并没有还给系统内核，而是在用户地址空间中被标记成保留块。这会引发一个问题，即：1 GB的虚拟地址空间就不再可用了。因此，仅当我们考虑对进程用 /LARGEADDRESSAWARE 参数进行编译时方可使用/3GB 参数。不恰当的使用/3GB 参数非但不能解决什么问题，反而会引起更多的问题。

从 Domino 7.0.1 开始，Domino 服务器可执行程序采用 Large Address Aware 参数进行编译，使之可以利用多达3 GB的地址空间。从应用程序层面来看，能额外使用1 GB地址空间，这已经可以满足要求。

内核层 - 应用层的因素不是我们唯一要考虑的问题。关于内核级的性能有更重要的因素。 当在 Windows 32 位操作系统中使用 /3GB 参数时，事实上，有1 GB内核地址空间被拿走，然后分给了用户地址空间。这就意味着可用的内核地址空间减少了一半。

某些复杂的应用程序在其进程使用的地址空间之外可能还需要分配额外的空间，使用这个参数的问题在于系统内核必须缩减内存占用，因为可用空间只剩下1 GB。由于系统从引导后进入了/3GB 模式，这不仅会影响那些使用3 GB用户地址空间的进程，而且内核地址空间是由所有的进程分享，还将会影响到系统内所有的进程。这可能会导致出现潜在的性能问题，特别是某些内核模式组件，如分页池、未分页池以及和系统页表项（PTE）。

具体的说，使用/3GB 参数会将 Windows 2003 分页池的最大值从470 MB减至200 MB以下。根据默认策略分页池大小为80%，那么分页池的平均大小在160MB左右，远低于通常期望和预期的值。由于 Domino 服务器每打开一个 1 MB大小的数据库就要消耗约 1 KB的分页池。在最坏的情况下，Windows操作系统事件日志里会出现Event ID编号2020的记录，Domino也会时常报告"Hardware/OS error (Insufficient system resources exist to complete the requested service)" “硬件/操作系统错误（系统资源不足以完成请求的服务）”。

此外，在 Windows 32 位操作系统上启用 /3GB 参数时，Lotus Domino 性能测试结果显示CPU占用率上升了10%~15%（因为受限内核增加了额外的空间开销）。测试结果还显示，启用 /3GB 参数后，Domino 服务器在Windows2003 下的表现比在 Windows2000 下更好。

/USERVA 参数
Windows 2003 平台上，还有一个额外的参数可以与 /3GB 参数一起使用，那就是 /userva 参数。你可以用 /userva 参数来调整分给用户模式的地址空间，值（以MB计）允许设置的范围是：2048 MB（2 GB）至 3072 MB（3 GB）。由于某些应用可能用不了 3 GB 空间，只分配 2.8 GB 就可以正常运行，就可以使用这个参数，允许 3 GB 空间中的剩余部分返回给内核使用。内核可用空间的增加使得系统页表项（PTE）的大小也得以增长。举个例子，在boot.ini中加入下列，就可以分配 2800 MB (2.73 GB)给用户地址空间，另外 1296 MB (1.26GB)给系统内核使用：

/3GB/Userva=2800

微软通常建议您设置 /userva 参数的值在2900 MB和3030 MB之间。然而，性能测试结果表明，/userva=2800 时 Domino 服务器就可以正常运行。重申一下，仅在 Domino7 和更高版本中支持这一选项。要了解更多关于 /userva 参数的信息，请看以下这篇微软技术文档：http://support.microsoft.com/kb/316739

内存和地址空间大小

让我们花些时间来强调一个重要因素。用户和内核地址空间大小的分配不会改变系统安装的物理内存总量。此外，物理内存和地址空间之间也不是一对一的关系。地址空间中已访问的页面既可以存在于物理内存中，也可以存在于页面文件中；把这两个数相加就是整体的虚拟内存占用。

事实上，进程的用户地址空间增加至3 GB并不意味着它就会占用3 GB的物理内存。简单地说，它只意味着允许操作系统分配3 GB的虚拟内存给这个进程。事实上还是由系统内核来决定哪些数据存入磁盘，哪些数据留在物理内存中。所以，在实践中，进程占用的用户地址空间每次只占用物理内存中有限的几个页面。

换句话说：进程不能提出使用多少物理内存的需求。这个决定权在内核，系统内核决定哪些数据留在物理内存中，哪些数据转存到页面文件。大多数情况下，从技术的角度看，进程并不知晓哪一部分数据会被写入或转出页面文件。更简单的概括，应用程序不区分物理内存和页面文件。因此，我们不能直接地讨论一个特定的应用需要多少物理内存，但只能讨论理论上它会用多少虚拟内存。

误解

你大概会想：“OK,如果我使用/3GB 参数，并且我有8GB的物理内存，应该是3GB的物理内存给 Domino 的分区#1，3GB的物理内存给 Domino 的分区#2，剩下的2GB 物理内存给内核，对吗？”

这种想法是错误的。

避免将物理内存和地址空间扯上一对一的关系很重要。虽然这些概念彼此之间有联系，但他们不是同义词。再说一遍，任何时候，单一进程大部分的用户地址空间通常指向磁盘上的页面，只有一小部分的地址空间指向物理内存。单一进程需要占用多少物理内存不是预先计算好的；它依赖于进程和系统事件，最终是由运行时的内核来决定。要估算特定环境下物理内存占用值的大小，唯一的方法就是通过模拟用户负载（尽量模拟实际环境）来实现。

你也许会想：“如果我的物理内存低于2 GB，假设我用/3GB 参数的话，内核和 Domino 占用多少物理内存？Domino占用3/4，内核占用1/4？”

再次强调，你不能把物理内存和用户地址空间扯上直接关系。尽管你的物理内存少于2 GB，用户地址空间还是3 GB不变（这里假设启用了/3GB 参数）。安装的物理内存很少仅仅意味着内核可能会控制更频繁的将地址空间写入页面文件。

以上段落的主要含义是，/3GB 参数是用于调整进程的地址空间、而非物理内存占用的多少，内存不足现象反映的是地址空间有限制，而非物理内存占用太多。

/PAE 参数
Windows 平台上，默认情况下内核可以管理最大4GB的物理内存（这不包括页面文件）。然而，在某些 Windows 版本，比如高级版的Windows 2000和2003中，管理员可以通过在boot.ini 文件中加入/PAE 参数来增加可以管理的物理内存上限。加入/PAE（物理地址扩展）参数允许内核识别并管理多达64 GB的物理内存。Windows 的不同版本能管理的物理内存上限也有差别，但不会超过64 GB。当然，为了利用/PAE 参数，您需要选择合适的，支持36位地址总线的内存控制器的硬件配置。

使用/PAE 参数设置不会影响32位应用可寻址的虚拟地址空间大小，仅会影响CPU及系统内核可管理的物理内存总量。

总结：

• /3GB 影响每个进程的虚拟用户地址空间
• /PAE 影响操作系统可管理的物理内存总量

/PAE 参数影响 CPU 能够寻址的物理内存总量。页面文件的使用不会受这个参数的影响，因为页面文件是顺序存放在磁盘上。未启用/PAE 时，系统中所有进程加起来就可能会使用远大于4 GB的虚拟内存，其中大部分占用的是页面文件，而只有部分占用的是物理内存。操作系统内核原本可以管理全部的物理内存，并允许所有32 位应用程序累计使用远超过4 GB的虚拟内存。换句话说，如果您要使用超过4 GB的虚拟内存（包括物理内存和页面文件之和），您不必启用/PAE 参数，只有在您要使用超过4 GB的物理内存时，才需要启用/PAE 参数。

下表提供了各种版本Windows操作系统（启用/PAE 后）支持的物理内存上限。以下信息摘自 MSDN 文章 Q283037 和 Q292934 ：

32位版本的Windows 操作系统

启用 /PAE 参数后支持的物理内存上限

32位版本的Windows 操作系统                   启用 /PAE 参数后支持的物理内存上限
Windows XP Professional                            4G
Windows 2000 Server                                4G
Windows 2003 Server                                4G
Windows 2000 Advanced Server                       8G
Windows 2003 Enterprise Server                     32G
Windows 2000 Datacenter Server                     64G
Windows 2003 Datacenter Server                     64G
Windows 2000/2003 Datacenter Server (with /3GB)    16G

/3GB 和/PAE
同时启用 /PAE 和/3GB 在某种程度上会制造冲突。为了支持使用更多的物理内存，加入/PAE 参数后，内核占用了更多空间。然而，当启用/3GB 参数时，内核可用的地址空间反倒变少了。最终结果是处于内核对地址空间利用的考虑，如果同时启用 /3GB 和 /PAE 参数，系统处理不了超过16 GB的物理内存。MSDN 网站一篇题为“Large Memory Support is Available in Windows 2000”的文章（Q283037）中有下列描述：

需要3 GB内存的应用程序很可能占用更多物理内存，而不是交换文件，从而提升能够使用/3GB 参数的应用程序的性能。有一种例外情况，即当同时启用/3GB 参数与/PAE 参数时，操作系统无法管理超过16 GB的物理内存。这是出于内核的虚拟内存空间考虑。也就是说，当在boot.ini加入/3GB 参数后，当系统安装了超过16 Gb的物理内存时，超过16 GB的部分不会被操作系统使用。

IBM Lotus 关于/3GB 参数的建议
既然 Domino7 服务器是可以访问大地址(Large Address Aware)的应用程序，并且看起来增加 Domino7 服务器的地址空间这种做法似乎很有吸引力，Lotus 支持部门并不建议您启用/3GB 参数，除非您别无选择。减少内核的地址空间可能会对性能带来负面影响，其本质是窃取原本属于系统内核的资源将其分配给用户应用程序使用。因为 Domino 6 应用程序不能够访问大地址，所以在Domino 6 上使用/3GB 参数是没有任何效果的，仅仅是减少了内核的地址空间。
您可以通过下列方法避免服务器由于2 GB的限制而宕机：
1. 使用/3GB 参数：如上所述，这个方法是最不可行的，Lotus技术支持通常也不推荐用户使用。如果您坚持使用这个选项，请考虑加入/userva=2800 参数。因为它潜在的约束，强烈建议在应用于生产环境中之前，先在测试环境中对这个配置进行测试。

2. 优化内存：降低内存占用，包括降低共享内存大小，减少线程数量，重新设计应用和代理。在一些用户案例中，产品缺陷或错误配置可能导致内存占用过高，超过预期，这种情况下必须采取一些措施来解决这个问题。在遇到内存占用过高的问题时，建议您联系IBM Lotus技术支持中心寻求帮助。

3. 启用 Domino 服务器分区：在未发现任何已知 Domino 产品缺陷，在配置修改或选项修改又没有更多的选择时，一个可行的方案是对 Domino 启用多个分区，将用户负载分散到不同的分区上。由于每个 Domino 分区都有各自的寻址空间集合，通过划分多个分区并加载应用程序，可以争取到更多虚拟内存供机动使用（假设 Domino 服务器不受硬件限制）。同样，您也可以在VMWare虚拟机上启用 Domino 分区来实现想要的目的。

4. 在 64 位的 Windows 2003上运行：另一个选择是在 64 位的 Windows 操作系统上运行32 位的 Domino 服务器。这样操作可以将内核的地址空间从分配给 32 位应用程序的地址空间移出，并移入一个独立的 64 位地址空间。对于采用了 Large Address Aware 选项进行编译的Domino 7 服务器，就可以占用 32 位应用程序可用的用户地址空间上限（即4 GB）。对于未采用Large Address Aware 选项进行编译的Domino 6 服务器，缺省情况下仍然有2 GB的用户地址空间限制。关于在 64 位的 Windows平台运行32位应用程序，还有其他忠告，请参阅相关信息。

5. 运行 64 位版本的 Domino 应用程序：Domino 8 的64 位版本会彻底摆脱32 位版本受制于地址空间的局面，提供更大的地址空间。然而，出于对保持服务器稳定均衡运行的考虑，其他一些来自操作系统或 Domino 的限制仍然无法回避。别忘了，在纯 64 位环境中，您可能仍会遇到硬件资源的限制（理论上，单个64 位的进程仍然可能会耗尽系统中所有可用的物理内存）。关于Domino 8 64位版本的详情，请参考以下信息：


相关的微软信息
在64 位Windows 操作系统下，没必要再使用/3GB 参数或/PAE 参数了，因为在默认配置时，64位内核完全可以管理更大容量的物理内存。另外，如上所述，每个32位进程在用户模式下几乎都能使用多达4 GB的空间（假设应用程序按 Large Address Aware选项编译）。

下表摘自微软技术文档#294418，略有改动，请查阅微软题为“Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003”的文档

64位版本Windows XP和Windows Server 2003的32位和64位内存体系结构的比较
http://support.microsoft.com/kb/294418
Windows Server 2003和Windows 2000支持大容量内存
http://support.microsoft.com/kb/Q283037
怎样使用/userva 参数和/3GB 参数来调整用户模式下的空间值在2GB和3GB之间
http://support.microsoft.com/kb/316739
内存支持和Windows操作系统
http://support.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Windows 2000 Datacenter Server不能定位大于16GB的内存
http://support.microsoft.com/kb/Q292934
在Windows Server 2003基础系统上的Exchange Server 2003中使用/3GB 参数
http://support.microsoft.com/default.aspx?scid=kb;en-us;823440
在系统分页池中不能分配内存
http://support.microsoft.com/kb/312362

微软解释：

https://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx

原文地址 http://blog.sina.com.cn/s/blog_494f9a6b0102e2gc.html