在虚拟机中运行任何东西都会对性能造成一定程度的影响，但是它实际上对数据库系统的性能有多大影响？ ，但这仅是使用Xen和PostgreSQL的有限测试。结论是使用VM不会“付出高昂的性能代价”（尽管您可能会认为实际数据另有说明）。
与之相关的技术，管理和其他缺点是什么？请在虚拟机中运行数据库？ ，但这对我们无济于事。
，
在虚拟机中运行数据库时会出现什么问题？ （请发表引用）
这些问题重要吗？
它们仅在某些情况下有意义吗？
解决方法是什么？
#1 楼
尽管许多数据库供应商对此非常缓慢，但是现在几乎所有供应商都正式支持其在虚拟化环境中运行的软件。我们在ESXi之上的linux中运行许多Oracle 11g实例，当然可以获得非常好的性能。与所有硬件扩展一样，您只需要确保虚拟化主机具有足够的资源（RAM，CPU），并且磁盘层就可以完成提供所需的IO性能的任务。
评论
+1如前所述，至关重要的是，资源要取决于任务。磁盘一直是我们的最大瓶颈，需要仔细计划。
–戴夫M
2011年9月1日14:41
+1您需要提前完成数据库使用方面的作业。如果您的物理设备利用率超过40％，那么您进行虚拟化处理的优势就会消失。话虽这么说，但我们在虚拟机上运行着无数小型的特定于应用程序的独立sql，这没有问题。但是由于缺乏优势，我们的大型重型机器具有专用硬件。
–内特
2011年9月1日15:04
毫无疑问，磁盘IO是最大的罪魁祸首，而虚拟化环境往往容易出错。
–lynxman
2011年9月1日15:13
@lynxman-同意。我们在15k SAS的Tier 1 SAN磁盘上运行所有Oracle实例。据我所知，我们非常接近原生性能。
–EEAA
2011年9月1日15:19在
“一盎司的测试值得一磅的猜测。”
–克里斯·贝伦斯（Chris B. Behrens）
2011年9月1日于21:05
#2 楼
正如ErikA所说，这正变得越来越普遍。我现在在SQL Server阵营中，个人没有在VM上运行任何生产系统，但我会毫不犹豫地（在对该主题进行了一些研究之后）。但是，在走那条路之前，肯定要考虑一些事情（至少对于SQL Server）。磁盘IO（如其他人所提到的）和内存分配只是两个示例。不同的管理程序之间的情况也将有所不同。Brent Ozar是虚拟化SQL Server（特别是在VMWare中）的公认专家。我强烈建议您阅读他的材料。
http://www.brentozar.com/community/virtualization-best-practices/
#3 楼
有可以，然后有应该。一辆轻型巡洋舰可以时速150英里/小时，但您应该在公共高速公路上吗？您可以不必要地伤害自己。数据库是来宾操作系统。通过设计，当他们启动时，他们会抢占资源块并出于性能原因直接对其进行管理。在虚拟化托管环境中将数据库服务器的核心操作系统作为访客后，您将在虚拟机管理程序中将仲裁层放置在磁盘和RAM的块分配元素与数据库服务器之间。它会变慢。您的查询效率越低，速度越慢。这些低效率今天可能会在专用硬件上被掩盖，但是，一旦您将仲裁引入到您的依存资源中，您就会很快发现真正的问题。认识到数据库服务器作为来宾操作系统提供了自己的整合层。没有理由不能移动一个物理服务器上的多个逻辑数据库实例，甚至不能移动IP地址，设置其他主机名等，以免发生这种自然的服务合并。而且，使用此模型，您不仅可以保留管理层为减少物理主机数量而推动的成本节省，而且还可以保留对物理资源的块访问，而不会影响任意虚拟机管理程序，这有时可以做出有益的决定，而不能做出决定。其他。
其他来宾操作系统（例如Java）也是如此。虚拟化解决方案通常在繁忙的环境中，管理程序必须对谁在资源上“获得令牌”做出很多决定。每当您可以消除该层时，您都会变得更好。
首先使用自然来宾操作系统层合并多个实例。奇怪的是，您将能够更轻松地实现平台整合和性能目标。
评论
“来宾操作系统”的有趣定义。尽管您的观点是关于纯净，纯净的性能，但您的数据库多久真正遇到CPU瓶颈呢？ I / O的可能性更大，对于性能更高的应用程序，您已经在SAN上共享I / O时间。我希望当一个应用程序的安全问题危及到所有统一数据库的密码哈希时，或者当JVM中运行的一个进程占用可用字节空间的每个字节时，您会重新考虑您的虚拟化原理。
– Shane Madden
2011-09-1 23:03
明确地说，我完全同意，经过微调，非常繁忙的高性能数据库服务器应具有自己的物理硬件。但这不是常态，虚拟化的其他好处往往会超过性能损失，这在大多数工作负载下是无法区分的。
– Shane Madden
2011年9月1日23:07
我不同意您总是先进入现有合并层的观点。有时候这很有意义。但是，例如，请考虑在重新平衡资源的成本折衷之间，即在单个OS上合并多个数据库与在虚拟机管理程序之上合并多个数据库/ OS组合之间。第一个是更有效的。第二个更容易重新平衡。与将数据库迁移到新的操作系统相比，将OS /数据库迁移到新的主机所造成的破坏要小得多。
–杰克·奥辛斯（Jake Oshins）
2011年9月2日，0：43
我的评论来自对作为性能工程师在过去十年中向虚拟化解决方案成功迁移和失败迁移的直接现场观察。那里有大量不良的数据库应用程序，它们滥用硬件掩盖了性能问题。添加虚拟化后，这些问题就暴露出来了。如果您有一个需要精确时钟以进行计时或审核的应用程序，那么由于时钟悬浮在软件虚拟化中，您将无所适从。
–詹姆斯·普利（James Pulley）
2011年9月2日，12：56
哇，詹姆斯，哇。我没有时间也没有耐心去浪费您在答案和后续评论中提出的所有观点，但我只是觉得我需要在这里为可能会回答此问题的任何人发表评论。詹姆斯的观点很好，是他自己的观点，并没有反映出真正可能的事情。如果您订阅过多，那么您的性能当然会很差。因此，不要超额认购。拥有非常高性能的虚拟化环境是完全可能的。对它提出一揽子建议是愚蠢的，因为它“表现不佳”。
–EEAA
2011年9月2日14:56在
#4 楼
这里有两件事要实现：对于虚拟化的数据库，每单位硬件的DB性能单位要低一些。这意味着您需要购买更多的硬件才能获得相同的性能水平。这并不意味着无法获得相同的水平或所需的性能水平。改进的管理和其他好处（例如更容易的HA）所带来的收益通常可以抵消略微增加的硬件成本。我无意很快进行虚拟化（另一个是主DC）。
#5 楼
只要您可以为VM提供足够的资源来运行您的应用程序，运行SQL Server的VM就可以了。如果在物理环境中需要24个内核和256 Gig的RAM，那么在虚拟环境中需要提供24个vCPU和256 Gig的RAM。有关在VMware vSphere上运行SQL Server的所有内容。#6 楼
我在dom0高度可用的虚拟环境（Xen）中运行两个数据库，一个是PostgreSQL，另一个是MySQL。 domU文件系统全部位于iSCSI SAN LUN上，并由LVM2逻辑卷组成。 MySQL数据库仅用于Cacti，因此根本看不到太多使用情况，它也位于iSCSI LUN上。PostgreSQL数据库是用于我们的暂存环境的数据库，因此比MySQL数据库具有更高的利用率。因此，数据库位于本地RAID10集上，并且DRBD复制到第二个群集节点。但是，就实际负载而言，此登台数据库根本看不到很高的负载。在我看来，这使其成为虚拟化的好选择。
对我们组织来说，一些好处是降低了功耗，节省了机架空间并减少了硬件管理开销。
另一方面，我们的主要生产数据库我无法想象要虚拟化....
#7 楼
我在许多服务器上使用MSSQL和MySQL服务器。几年前，我很犹豫开始在VM上设置SQL Server，因为我听说过在VM上运行SQL Server的性能问题。但是，在设置了第一批SQL服务器之后，我没有感到任何惊讶，但发现性能没有变化。我使用的越来越多的服务器都在VM上，并且我工作的几乎所有大型企业客户端都使用了SQL服务器。是的，VM确实增加了一些开销成本，如果要在一个盒子上托管多个VM，则将需要一台功能强大的服务器。要寻找的常见资源问题是添加其他VM并减少可用资源。计划增长是一种常见的做法，但是，如果您购买了服务器来托管2或3个VM，并且现在运行10个VM，您的性能可能会受到打击。
如果我说从未见过在VM上运行SQL Server的性能问题，那我会撒谎。但是，我了解到，如果您看到性能不佳，则环境可能存在问题。
评论
+1我主要想听听有关SQL Server和Windows 2008 R2方案的反馈@Shane Madden-您能解释一下关闭吗？我希望动机是由一个非特定的答案（然后在评论中偏离）驱动的，而不是问题本身。关于该问题，在封闭前存在的大约一天之内，有44票和12个最爱对我来说是一个很好的问题，具有有用的答案/信息（尤其是与ServerFault问题流量的典型情况相比）。这就是各个SE网站所针对的。您是否宁愿选择一个更具体的问题措词，而不是宽松的“问题有多严重？”。
@ ErikA，Shane，Womble，mikeyb，Ben-我进行了社区编辑，可能使这个问题更具建设性。请考虑重新打开该问题，或在新问题/未解决问题上发布类似问题。
在将近10年后，我对今天的情况感到好奇。