当您知道您的软件（不是驱动程序，不是操作系统的一部分，只是一个应用程序）将主要在虚拟化环境中运行时，是否存在优化代码和/或编译器设置的策略？或者你应该和不应该做什么的指南？
这并不是性能提升0.0％，但可能只是可能有一些简单的事情可以大幅改善性能，或者看起来很简单，但在虚拟化环境中却是灾难性的。例如，在内核构建中启用CONFIG_PARAVIRT很容易，并且可以大大提高性能。现在我正在为应用程序寻找类似的东西，如果有的话。
在我的情况下，它将是C ++代码，可能是VMWare，但我想将问题保持为尽可能与语言/产品无关。我想知道是否有这样的策略，或者这是否完全浪费时间 - 毕竟虚拟化的概念是你不必过多关心它。
答案 0 :(得分：4)
我发现它完全与I / O有关。
虚拟机通常在IO上非常糟糕。这使得各种事情比真正的锡更糟糕。
交换特别是一个糟糕的杀手 - 它完全破坏了虚拟机性能，甚至一点点，因为IO速度很慢。
大多数实现在VM之间存在大量的IO争用，我没有看到一个可以避免这种情况或合理处理它的问题。
如果可以，请使用ramdisc作为临时文件，但不要让它交换，因为那会更糟。
答案 1 :(得分：3)
我能给你的唯一建议是小心使用mlock（）/ mlockall（）..同时寻找有气球的气球驾驶员。
例如，如果Xen客户机以1GB启动，然后迅速降至512 MB，那么特权域通常不会查看半虚拟化内核实际承诺向进程承诺多少内存（即Committed_AS）。实际上，对于Xen，除非将此值放在Xenbus上，否则特权主机不知道这样的气球会做什么。我相信这也与KVM一致，取决于内核的配置方式......但是你的问题假设我们对这些事情一无所知：）
所以，保护那些根本无法被分页的东西（小心但谨慎），总是考虑到“天空正在下降”的情景。
同样地，使用posix_fadvise（）/ posix_madvise（）告诉PV内核你做了多少或者不需要缓冲总是一个好主意。
除此之外，您可以做的事情很少......因为您只谈论半虚拟化内核，该内核旨在使流程首先无视虚拟化。
我还没有使用KVM，但我计划将来更多地探索它。但是，我最近写的90％的内容都专门设计用于在半虚拟化Xen客户端上运行。很抱歉有点以Xen / C为中心，但这就是我的经验，pv_ops在主线上（很快也是xen-0操作）：）
好问题，顺便说一下：）
修改
当我说“谨慎但谨慎”时，我的意思是保守一步。如果您的程序分配了大多数函数所需的某些作业结构，请将其锁定。如果您分配缓冲区来读取大文件，请不要锁定它们。并确保调用posix_fadvise（）让内核知道您只打算访问它一次（如果是这种情况）。另外，请务必告知内核使用内存映射文件，特别是如果它们用于组织并发。
简而言之，帮助您的主机内核管理内存，不要让关键的已分配块被抛入脏分页中，不要假设您的程序比锁定其分配的所有内容更重要：）
对于歧义感到抱歉。我能想出的最好的一句话是“谨慎但谨慎”。
答案 2 :(得分：1)
我唯一的建议是尽可能保持你的记忆力和IO使用率低。
与物理硬件相比，VM中的IO速度非常慢。如果你可以避免这样做，那就避免它。
答案 3 :(得分：1)
当系统虚拟化时，真实硬件上速度慢的东西甚至会变慢。这取决于所使用的虚拟化技术变得多慢。
特别要避免任何需要与虚拟环境之外的世界进行I / O的事情。取决于设置的方式，这包括在屏幕上绘图，交换以及磁盘和网络I / O.这大致是重要性的降序。
如果可能的话，假装你正在为一台已有10年历史的电脑写作。如果你的应用程序适用于1999台式电脑或笔记本电脑，它应该可以。