我们曾使用过 SQL Server Express - 各种版本都没有问题。但是，我们在 VMware 机器上安装了它，但存在严重的性能问题。我联系了 VMware 和 Microsoft - Microsoft 不明确支持 Express，因为它是免费版本。问题是，随着数据库变大，物理机和 VMware 之间的性能差距会越来越大。VM 目前比安装了 4GB SQL Server 2008 R2 Express（限制为 10GB）的类似规格的物理机慢约 5 倍。VM 上有一个巨大的 VMware 服务占用了 VM 上可用的 3.5 GB 内存中的 1GB。我正在寻找资源，试图找出是否可以提高性能。非常感谢链接和评论。
答案1
您看到的“巨大的 vmware 服务”很可能是由于记忆膨胀这会在 ESX 主机的物理内存不足的情况下发生。观察到的系统完全利用率在不执行任何操作时的时间可能反过来是等待 ESX 主机端发生交换 I/O 的时间。当 ESX 正在交换页面时（同样，由于内存不足），它会暂停客户机，从而只留下几个周期用于实际处理。
答案2
这并不奇怪。按照许多传统标准，在这种情况下，数据库操作系统是运行在 Windows 上的客户操作系统。启动时，它会立即获取一块 RAM 和一块磁盘，SQL Server 出于性能原因希望自行管理这些 RAM 和磁盘。只要您要求主机成为 VMWARE 中的客户，您就会在与 SQL Server 性能相关的磁盘和内存访问中引入另一层仲裁。客户操作系统的另一个特点是它们往往有自己的自然整合层来保持性能。对于 SQL Server，虽然不一定是 SQL Express，但您可以在单个硬件上合并多个数据库实例，从而保持数据库引擎的性能和对资源的访问，同时降低许多推动高层管理虚拟化的成本项目。
正如您所说，随着越来越多的数据被添加，性能会变得越来越差，这意味着您需要访问越来越多的磁盘才能获取信息。每个请求都必须由虚拟机管理程序进行仲裁，然后才能真正到达磁盘，磁盘访问量越大，仲裁延迟所造成的所有这些微秒的累积损失就越大。在这种情况下，您能做的最好的事情就是检查您的查询。确保它们在生产中非常高效，尽可能使用索引来最大限度地减少表扫描活动（当响应时间与数据表大小直接相关时，通常就是这种情况）。您对磁盘子系统发出的请求越少，虚拟机管理程序仲裁请求的机会就越少，系统的速度就越快。
如果您的数据以相当快的速度增长，那么您将希望考虑其他选项，因为您很可能会很快耗尽 SQL Express 处理越来越大数据集的能力……而且这通常发生在您必须将数据移出门外的尴尬时刻。我认为 SQL Express 2088 R2 的限制是 10GB。这不是一个微不足道的数据量，但如今似乎很容易超出这个数据量。
答案3
用于磁盘访问的 Hypervisor 层不会引起这么大的问题。虚拟机在后端做什么？听起来它可能正在膨胀内存并与 VMware 服务器上的其他资源争夺 RAM 或 CPU 争用。您正在运行哪个版本的 VMware？您的内存和 CPU 资源的过度使用程度如何？我运行了大约 400 个带有 SQL 服务器的虚拟机，它们没有遇到问题。但我的 RAM 并没有过度使用。
答案4
好的，所以 vmWare 不应该使用 1G3- 有记录表明内存泄漏是由于某种可重入 IP 问题造成的。重新启动机器（如果有疑问，请将其关闭并再次打开）可以清除该问题。另一方面，SQL Express 不应该占用 3GB。根据 MS，这应该是 1GB 的限制。SQL Express 内存（手动）固定在 786MB - 小吗？增加或减少 256M 似乎都更糟，但变化并不大，所以我们选择了中间值。vmWare 正在缓慢增加 - 最多达到 89MB - 最初约为 10MB。请注意，使用 SQL 2008，您可以更改内存而无需重新启动（SQL）服务。