我们使用了-没有问题的各种版本。但是,我们在VMware机器上安装了一个程序,并且存在严重的性能问题。我已经联系过VMware和微软-微软并不明确支持它的免费版本。问题是,随着数据库越来越大,物理机器与VMware之间的性能差距越来越大。VM当前比具有4GB Server 2008 R2 Express安装(限制为10 4GB)的类似规范的物理机器慢5倍。有一个巨大的VMware服务可以在VM上使用3.5GB的Memeory中的1GB以上。我正在寻找资源,试图找出是否可以提高性能。链接,评论非常感谢。
发布于 2011-10-09 13:04:48
您所看到的“巨大的vmware服务”很可能是由于记忆膨胀造成的,在ESX主机上出现物理内存不足的情况下会发生这种情况。当它不做任何事情时,所观察到的全系统利用率周期可能是等待交换I/O发生在ESX主机端的时间。当ESX正在交换页面时(同样由于内存不足),它会使来宾停止,因此只留下几个周期用于实际处理。
发布于 2011-09-23 13:46:18
这并不令人惊讶。根据许多传统标准,在这种情况下,数据库操作系统是运行在Windows之上的来宾操作系统。当它启动时,它会立即抓取SQL服务器出于性能原因希望自己管理的一块RAM和一块磁盘。一旦您要求主机成为VMWARE中的来宾,您就会在访问与Server性能相关的磁盘和内存方面引入另一层仲裁。客户操作系统的另一个特点是,它们倾向于拥有自己的自然整合层来保持性能。在Server的情况下,虽然不一定是Server,但您可以将多个数据库实例合并到一个硬件上,从而维护数据库引擎的性能和对资源的访问,同时影响许多成本项目,这些成本项目正从上层管理中驱动虚拟化。
您注意到,随着数据的增加,性能会变得越来越差,这意味着您可以更好地访问磁盘以获取信息。这些请求中的每一项都必须在虚拟机监控程序实际命中磁盘之前进行仲裁,并且磁盘访问越多,所有这些微秒在仲裁延迟上的累积代价就越大。在这种情况下,最好的方法是检查查询。确保它们在生产中是高效率的,并且在可能的情况下使用索引来最小化表扫描活动(通常是在响应时间与数据表大小直接相关时)。向磁盘子系统提出的请求越少,虚拟机管理程序对请求的仲裁机会就越少,系统变得越快。
如果您的数据正在以相当好的速度增长,那么您将希望看到其他的选项向前发展,因为您可能会耗尽sets更快地访问越来越大的数据集的能力,而不是later....and,这通常是在您不得不将数据从门上取出的尴尬时刻出现的。我认为2088 R2的限制是10 on。这并不是一种虚无缥缈的数据,而是一种最近似乎很容易被超越的数据。
发布于 2011-09-23 14:13:42
用于磁盘访问的Hypervisor层不会引起这么大的问题。VM在后端做什么?听起来,这可能是在膨胀内存,并与VMware服务器上的其他资源争夺内存或CPU。您运行的是什么版本的VMware?您的内存和CPU资源有多大?我运行了大约400个带有SQL服务器的VM,它们没有遇到问题。但我对RAM的投入还不够。
https://serverfault.com/questions/312730
复制相似问题