☰

虚拟 Windows 服务器和页面文件位置

tag-icon • tag-icon vmware-esx
虚拟 Windows 服务器和页面文件位置

考虑到即使有大量可用 RAM，Windows 也会大量使用页面文件，将此页面文件放在尽可能靠近虚拟系统的最快磁盘上不是最好的吗？

我在想，RAM 磁盘。

在我工作的地方，虚拟机的存储位于 NAS/SAN 上。我担心如此多的内存访问必须通过网络进行！

顺便说一句，我认为微软是时候摆脱分页并告诉我们购买更多的 DIMMS 了。

更新

访问本地主轴比访问 DIMM 慢 40,000 倍，因此对于硬故障，通过网络访问会更慢。我不知道为什么我被否决了，我确信这是一个问题，除非 ESX/HyperV 中有其他机制可以管理这个问题。

最后更新

我发现了一些与此相关的有用的链接和建议。

来自 Netapp 论坛：

将虚拟机 (VM) vswap 和临时/页面文件托管在 NetApp 存储系统上不同卷上的单独 NFS 数据存储中。（分离瞬态数据可以更快地完成 NetApp Snapshot 副本并实现更高的存储效率。）

摘自 thebitsthatbyte.com：

Hyper-V VM 性能提示：将页面文件 (pagefile.sys) 移动到另一个虚拟磁盘

来自 VMinstall.com：

在每个 ESXi 群集中为客户机 SWAP 文件设置一个数据存储，参见右图。（请勿使用本地 ESX 磁盘！这将节省更昂贵的 SAN 存储，但会导致虚拟机的 DRS 和 vMotioning 延迟。）

摘自 pubs.vmware.com 上的 ESX 4 故障排除建议：

对于资源密集型虚拟机，请将虚拟机的物理磁盘驱动器与具有系统页面文件的驱动器分开。这可缓解高使用率期间的磁盘主轴争用问题。

答案1

您可以将虚拟机的交换区域（虚拟机管理程序用来交换 vRAM 的区域）放置到更快的 LUN/数据存储区，该 LUN/数据存储区不使用精简配置，并由阵列中最快的主轴/NAND 支持，并将页面文件保留在操作系统的监督范围内及其操作系统安装分区中。监控交换区域使用情况和页面文件使用情况，并根据需要购买更多 vRAM 和 DIMM。其他任何事情都是过度的。

此外，由于虚拟内存的概念对于任何一个还算不错的操作系统和硬件平台来说都是必不可少的，因此摆脱磁盘分页的现象短期内是不会发生的。

答案2

好的，我认为您误解或错误估计了这里的一些基本概念，因此按照我在您的问题中看到的顺序，我们开始吧：

（1）您说，即使 RAM 充足，Windows 也会大量使用页面文件，这种说法是错误的。事实并非如此。

  • 页面文件可能保持相同的大小，但是否实际使用它来存储任何东西则是另一回事。分配（其中有多少东西）也与利用率（使用量/频率）有很大不同，仅仅因为 Windows 将大量内存内容加载到页面文件并不意味着它们将被大量使用，甚至根本不会使用。虚拟内存或 Windows 页面文件在概念上只是一个放置数据（“东西”）的地方，这些数据不是那么急迫或频繁地需要存储在 RAM 中，但比硬盘上其他地方的任意数据块（一些随机文件）更急迫或更频繁地需要。

（2）你想用[非常大的] RAM 磁盘解决这个不存在的问题的想法是行不通的。

  • 您可以在其中塞入一个 PB 级 RAM 磁盘，而 Windows（以及一般操作系统）仍将利用您允许的任何虚拟内存空间来存储它认为应该存储在虚拟内存中的任何数据，因为虚拟内存在概念层面上“只是”比普通磁盘访问速度更快，但比 RAM 访问速度慢的地方。由于 RAM 历来比磁盘空间昂贵且稀缺得多，因此这曾经（现在仍然）是降低计算成本的一个很好的折衷方案 - 如果数据不经常访问或预计很快会被访问，则不需要放在高成本、极快的访问芯片（RAM）上，因此您可以将它放在更便宜 [因此更慢]（“硬盘”）的地方，以允许优先数据占用该有限资源。

(3) 您担心的是对 SAN 性能完全不重要的事情。

  • SAN 是一种网络和存储系统，专门用于将大量数据从访问它们的计算机系统传输到 SAN 存储控制器中的磁盘。（当然还有其他功能，但这是主要功能。）有些人的唯一工作和人生的主要职责就是设计这些系统来实现这一点。他们为此投入了比我们其他人更多的思考、研究科学方法和高等数学。他们做知道自己在做什么，而且他们比你或我更有能力处理这些细节。

  • 或许更重要的是，交换（传输到/从虚拟内存）内存内容将只占 SAN 带宽的一小部分，除非您有大量机器进行大量交换，这将是显而易见的，因为这种级别的交换会导致机器无法使用。因此，除非您的环境是这种情况，否则由于交换而往返于 SAN 的相对数据传输量是微不足道的。您的 SAN 将看到大部分流量（以巨大的优势）来自通常与访问硬盘相关的活动。这些活动包括移动文件、保存或更改数据、读取和更新数据库等。如果确实需要优化往返于 SAN 的流量（以及您为什么这么认为 - 您的系统响应时间是否真的由于 SAN 带宽或吞吐量瓶颈而降低？），那么还有一长串比 Windows 服务器交换虚拟内存量更重要的考虑因素。

（4）关于您所说的微软应该如何摆脱分页的陈述......

  • 你的意思是“虚拟内存”而不是“分页”，因为分页实际上不是虚拟内存的同义词，而是一种包括使用虚拟内存的内存管理方案。

  • 无论哪种情况，这都不会发生，也不会有帮助……任何事物... 无论如何，这在很大程度上是无关紧要的，因为即使微软摆脱了虚拟内存，世界上大多数服务器、设备和计算设备通常也不会在基于微软的操作系统上运行。大多数运行基于 *nix 的操作系统，以及其他甚至比 UNIX 或 Linux 更不熟悉的更老的操作系统。

编辑：

为了回应您的评论（@LukePuplett），我也会将以下内容添加到我的答案中。

好吧，既然看起来您仍然不相信，并且仍然认为 Windows 分页会降低 SAN 性能，那么我建议您“计算一下”Windows 交换对 SAN I/O 的影响。您可以这样做：

  1. 监控（通过perfmon或其他方式）您的 Windows 服务器（或至少是其中的一个样本）以确定/估计您有多少个硬页面错误。这将是进入 SAN 的交换事件的数量。可能以每秒的速率计算，最好以每秒的速率计算。称之为[A]。
  2. 使用不同的计数器进行相同的监控，以确定页面事件的平均大小。可能为kiloBytes，转换为Bytes(乘以1000)。称之为[B]。
  3. 计算 SAN 的理论最大吞吐量瓶颈。这可能是（当然也是最容易计算的）您的 SAN 交换机/光纤的网络速度等级，例如，8 Gb/s 光纤通道 SAN 的最大理论吞吐量值为（或可能为）8Gb/s。由于这是bit/s，（在本例中）而您的其他值将是Bytes/s，因此将该值除以 8。将其称为[C]。

取 ( [A]* [B]*2)/[C]来获取分页数据所消耗的最大吞吐量百分比。（乘以 2，因为硬故障仅测量一个方向的数据传输，并且通常至少在理论上也会有相应的另一个方向的数据传输。将数据从 RAM 移动到虚拟内存的实例通常也应该对应于将磁盘存储的数据移动到 RAM。）

除非您的环境非常异常，否则根据我大约十年来从数十个不同环境中获取的指标，该值将与 SAN 最大吞吐量的十分之一 (0.1%) 处于同一数量级。如上所述，在原始答案文本中，还有一长串其他因素（实际上有几十个离散配置或我能脱口而出的因素），您可以通过调整从 SAN 中获得超过 0.1% 的“性能”改进，如果您的 SAN 确实会从性能调整中受益，而您完全没有提供任何证据表明这一点。

答案3

虽然 Windows 确实将页面文件用于不仅仅是内存过载的情况，但我认为这是疯狂的，只需为虚拟机提供所需的内存并单独处理存储性能问题 - 您的建议将是一个错误。

噢，页面文件很快就不会消失。

相关内容