当你知道你的软件(不是驱动程序,不是操作系统的一部分,只是一个应用程序)将主要在虚拟化环境中运行时,有没有策略来优化你的代码和/或编译器设置?或者你应该做什么和不应该做什么的任何指南?
这不是关于0.0x%的性能提升,而是可能,只是可能有一些简单的事情可以显著提高性能,或者一些看似简单但在虚拟化环境中却是灾难性的事情。例如,在内核构建中启用CONFIG_PARAVIRT很容易,并且可以极大地提高性能。现在我正在为应用程序寻找类似的东西,如果有的话。
在我的例子中,它将是C++代码,也可能是VMWare,但我想让这个问题尽可能地与语言/产品无关。我想知道是否有这样的策略,或者这是否完全是浪费时间-毕竟虚拟化的概念是你不必太在意它。
发布于 2009-03-05 08:58:32
我能给您的唯一建议是谨慎使用mlock() / mlockall()。同时还在找有问题的气球司机。
例如,如果一个Xen来宾操作系统启动时有1 MB的内存,然后降到了512MB,那么特权域通常不会查看半虚拟化内核实际承诺给进程(即Committed_AS)的内存量。实际上,对于Xen,除非将此值放在Xenbus上,否则特权主机不知道这样的气球将会做什么。我相信这也符合KVM,这取决于内核是如何配置的。但你的问题假设我们对这些事情一无所知:)
因此,保护那些根本不能被页出的东西(要小心,但要谨慎),一定要考虑到“天塌下来了”的情况。
同样,使用posix_fadvise() / posix_madvise()告诉PV内核您需要或不需要缓冲的程度总是一个好主意。
除此之外,你几乎无能为力..因为您只在讨论半虚拟化内核,它的设计目的是让进程在一开始就不受虚拟化的影响。
我(目前)并不经常使用KVM,但我计划在未来更多地探索它。然而,我最近写的90%的东西都是专门为在半虚拟化的Xen客户机上运行而设计的。很抱歉有点以Xen /C为中心,但这就是我的经验所在,而pv_ops是主线(很快也是xen-0ops) :)
问得好,顺便说一句:)
编辑:
当我说“谨慎但谨慎”时,我的意思是比保守高一步。如果您的程序分配了大多数函数所需的作业结构,请将其锁定。如果您分配缓冲区来读取大文件,请不要锁定它们。一定要调用posix_fadvise(),让内核知道您只打算访问它一次(如果是这样的话)。此外,一定要建议内核使用内存映射文件,特别是在它们用于组织并发的情况下。
简而言之,帮助您主机内核管理内存,不要让关键的已分配块被抛入脏分页,不要通过锁定它分配的所有内容来假定您的程序比其他任何东西都更重要:)
很抱歉我说得含糊不清。我能想到的最好的短语是‘小心,但谨慎’。
发布于 2009-03-05 10:39:08
我发现它都是关于I/O的。
VM通常在IO方面表现得非常糟糕。这使得各种各样的事情比真正的罐头上的事情更糟糕。
交换是一个特别糟糕的杀手-它完全破坏VM的性能,甚至是一点点,因为IO太慢了。
大多数实现都有大量的虚拟机之间的IO争用,我还没有看到一个可以避免或明智地处理它的实现。
因此,如果可以的话,请使用ramdisc存储临时文件,但不要让它交换,因为那样会更糟。
发布于 2009-03-05 09:18:57
我唯一的建议是尽可能降低内存和IO的使用率。
与物理硬件相比,虚拟机中的IO相当慢。如果你能避免做这件事,那就避免它。
https://stackoverflow.com/questions/613968
复制相似问题