关于是否应该处理页面文件，有很多讨论。此场景描述了我生产环境中真实存在的独特情况。为了解决问题，我得出的结论是禁用页面文件。
我正在运行一系列客户虚拟机，它们都是 Server 2003 Enterprise Edition（inorite？）。对于我的物理主机，我运行的是装有 VMware ESXi 5.0（通过 vCenter 管理）的 HP DL380 G7。对于存储，我有一个 HP P2000 G3 SAS 阵列，装有 16 个 300 GB 10k SAS 驱动器，采用 RAID 6，称为 LUN01。这些虚拟服务器组成了我们的 Wonderware 环境，其中包括一台 SQL 服务器和 Historian、两台应用程序服务器和两台终端服务器。
该堆栈执行的工作是任务关键型的，并决定该设施是否能够发挥其功能。（即，当服务器停机时，业务就会中断）最近，P2000 阵列中的几个磁盘故障促使我从头开始重新考虑架构。重建阵列中的磁盘严重损害了性能，以至于 Wonderware 应用程序完全没有响应。由于这些虚拟机都运行 I/O 密集型应用程序，因此 RAID 重建对 RAID 的要求很高。
我已确定磁盘重建期间的瓶颈是由于应用服务器磁盘写入而发生的。似乎是因为它使用的是系统页面文件而不是 RAM。因此，网络 I/O 的数量直接与磁盘 I/O 相关。因此，重建期间对磁盘的严重性能影响会直接影响 APP 服务器 I/O。它如此设计的原因很难理解，但它完美地解释了为什么一台不存储任何本地内容的服务器（应用服务器）会维持 10Mbps 的磁盘写入速率（应用服务器 VM 的 vmware 性能统计）。
所以......我的想法是，考虑到这种情况，我想禁用客户操作系统（服务器 2003 EE）中的页面文件，以防止部署的 Wonderware 应用引擎产生如此高的磁盘 I/O 需求......从而减轻未来磁盘重建对 RAID 的影响。
- 你怎么认为？
- 这是否可以证明禁用页面文件是合理的？
- 我是否忽略了另一种可最大限度减少 RAID 重建对性能影响的解决方案？
答案1
我不知道 Wonderware，但是如果您使用页面文件，那么您的内存就会不足，并且使用虚拟内存一切都会继续运行得更慢 - 禁用页面文件不一定能解决这个问题，它很可能只是让一切都耗尽内存并崩溃。
1）为主机购买更多 RAM，或在客户机中配置更多 RAM。
2）或者配置应用程序以使用更少的内存。
3）或者更有用的是，运行类似PSInternals 的 ProcMon看看客人电脑上实际写入磁盘的内容，并确认您的怀疑。
4) 如果您可以在 Windows Server 2008 R2 上运行类似配置的测试服务器，任务管理器会比 2003 更详细地显示磁盘访问情况（进程、文件、响应时间），而且没有 Process Monitor 的庞大日志文件。
这样设计的原因没有什么意义，但它完美地解释了为什么一个没有本地存储任何内容的服务器（应用服务器）能够维持 10Mbps 的磁盘写入速率（应用服务器 VM 的 vmware 性能统计）。
应用程序日志文件？临时文件（如报告或渲染模板及其输出）？通过应用程序的所有内容的事务日志？两个应用服务器之间的状态同步？流氓防病毒扫描程序？损坏的文件系统过滤驱动程序？恶意软件？
答案2
我花了很多时间与 Wonderware 通电话，终于搞清楚了这个问题。基本上，部署到 Galaxy 的每个 App Engine 中都有一个可配置的参数，称为“检查点周期”。
检查点周期是 Archestra 将应用程序的当前状态（值、变量等）写入磁盘的时间段。这样做的目的是，如果服务器重新启动或系统崩溃，应用程序可以从其最新状态恢复，而不会丢失数据。如果您的应用程序旨在将值存储在星系对象本身中，则必须权衡您可以容忍多少数据丢失。如果您的应用程序旨在仅处理数据，并将存储信息的工作卸载到 SQL 服务器或将值留在标记数据库中，那么增加此值不会有丢失任何数据的风险。
ArchestrA 目前有大约 9000 个标签。这意味着在任何两秒之间，9000 个值都可能发生变化，从而导致每秒有 9000 个值写入磁盘。这些值中的大多数会覆盖前一秒存储的值。用于监控模拟输入的系统每秒都会发生大量变化。作为管理员，您必须决定其中有多少是噪音，有多少数据需要捕获以进行趋势分析/跟踪等...
将默认值 0 毫秒（系统将其解释为“未指定默认值，使用 1 秒”）增加到 5000 毫秒，我的磁盘活动从超过 300 IOP 下降到不到 25 IOP。我们实际上将每个 App Engine 错开为接近 5000 毫秒的质数，以便每个引擎的检查点周期都会向磁盘发出独立的 I/O 活动请求。这对于控制系统的虚拟化尤为重要。当在同一阵列上运行许多服务器时，性能和可扩展性就会成为一个问题。