KVM性能优化最佳实践

冷不防 2023-10-08 08:48 74阅读 0赞

在本章中，我们将了解如何在KVM设置上进行性能调整。我们还将讨论可在KVM设置中应用的最佳实践，以提高性能。我们提供了一些步骤来调整不同的组件，例如CPU，内存，网络，块和计时。

性能调整是一个反复试验的过程。虚拟机托管不同类型的应用程序，因此所需的调整类型随虚拟机而变化。在大多数情况下，默认配置足以获得不错的性能。在性能调整之前，我们应该了解所有涉及的组件，可用的选项和子系统。然后，我们可以开始实施这些选项，收集结果，最后得出结论。在性能世界中不可能抢到并解决。必须通过反复试验的方法来完成。您的设置是裸机还是虚拟化。提高性能的一种常用方法是在受支持的硬件配置上运行软件，并始终确保满足最低/建议的配置以运行环境。如果不满足这些先决条件，它会极大地影响性能。另一种方法是分配所需的资源，而不是浪费大量资源。应该有适当的计划，因为环境将来可能会扩展。

在深入探讨虚拟机的虚拟化或性能调整之前，我想 回顾或重申KVM基础知识。正如我们在前面的章节中所讨论的，客户机系统或VM是主机系统中的简单Linux进程。vCPU是Linux POSIX线程。因此，显然，Linux的调度子系统或 Linux调度程序将处理这些线程/进程。不要对“线程”一词感到困惑；线程是Linux中的轻量级进程。如*第**2**章* *KVM* *内部细节*所述， 默认情况下，KVM继承了 Linux Kernel功能。 因此，NUMA 可以为KVM提供诸如大*页面之*类的内存支持，因为简而言之，KVM可以将Linux系统变成虚拟机监控程序。

本章对KVM可用的最佳做法和性能调整选项提供了一些见解。嗯，正如大家所说，*性能调优是一门艺术*。没有一种工具可以在所有情况下最大限度地提高性能。因为环境不同，所以必须相应地调整性能。

前面的章节讨论了KVM可用的半虚拟化驱动程序。

半虚拟化驱动程序旨在提高虚拟化性能。当我们谈论KVM时，半虚拟化驱动程序是virtio驱动程序。但是，Virtio驱动程序不限于KVM虚拟机管理程序。我们将从virtio驱动程序开始，然后深入探讨不同的子系统调整和最佳实践。

我们将涵盖以下主题：

• CPU和内存调整

• 了解NUMA，CPU和NUMA内存调整

• 磁盘和块I/O调整

• 网络调优

• KVM最佳做法

**VirtIO**

在虚拟化世界中，总是将裸机系统进行比较。半虚拟化的驱动程序可提高客户机的性能，并尝试保持接近裸机的性能。建议对完全虚拟化的虚拟机使用半虚拟化驱动程序，尤其是当虚拟机运行具有大量I/O的任务和应用程序时。Virtio是用于虚拟IO的API，由Rusty Russell开发以支持他自己的称为**lguest**的虚拟化解决方案。引入Virtio是为了实现用于IO虚拟化的虚拟机管理程序的通用框架。

简而言之，当我们使用半虚拟化驱动程序时，客户机操作系统意识到它正在虚拟机管理程序上运行，并且包含充当前端的驱动程序。前端驱动程序是客户机系统的一部分。当存在模拟设备并且有人要为这些设备实现后端驱动程序时，虚拟机监控程序将完成此工作。前端和后端驱动程序通过virtio进行通信。KVM使用virtio驱动程序作为半虚拟化设备驱动程序。这也可用于在KVM主机上运行的Windows客户机计算机：

来源：**[http][]**：**[//www.ibm.com/developerworks/library/l-virtio/][http]**

主要有两层（虚拟队列和虚拟环）来支持客户机和管理程序之间的通信。

虚拟队列和虚拟环（vring）是virtio中的传输机制实现。Virt队列（virtio）是连接前端和后端驱动程序的队列接口。每个virtio设备都有自己的virt队列，来自 客户机系统的请求将放入这些虚拟队列中。每个Virt队列都有其自己的环，称为vring，在此环中将内存映射到qemu和虚拟机之间。您可以在Linux内核的**./drivers**子目录中找到各种前端驱动程序的源代码。 KVM guest 虚拟机中可以使用不同的virtio驱动程序。

设备在QEMU中仿真，驱动程序是Linux内核的一部分， 或者是Windows guest 虚拟机的附加软件包。 设备/驱动程序对的一些示例：

•  **virtio-net**：virtio网络设备是虚拟以太网卡。Virtio-net为此提供了驱动程序。

•  **virtio-blk**：virtio块设备是简单的虚拟块设备（即磁盘）。Virtio-blk为虚拟块设备提供了块设备驱动程序。

•  **virtio-balloon**：virtio内存气球设备是用于管理客户机内存的设备。

•  **virtio-scsi**：virtio SCSI主机设备将一个或多个磁盘组合在一起，并允许使用SCSI协议与其通信。

•  **virtio-console**：virtio控制台设备是用于客户机和主机用户空间之间的数据输入和输出的简单设备。

•  **virtio-rng**：virtio熵设备提供高质量的随机性以供客人使用，等等。

通常，您应该在KVM设置中使用这些virtio设备以获得 更好的性能。

要了解更多关于为Virtio规范是指**[http://docs.oasis-open.org/][http_docs.oasis-open.org][为Virtio /已将virtio/V1.0 /已将virtio-v1.0.html][http_docs.oasis-open.org]**[。][http_docs.oasis-open.org]

**CPU****调整**

我想重申一下，vCPU是KVM主机中的POSIX线程。您可以根据需要为客户机系统分配vCPU。但是，为了获得最大或最佳性能，始终最好根据客户机操作系统的预期负载为每个客户机分配所需的虚拟CPU。分配超出需要的内容没有错；但是，当将主机系统视为一个为所有已配置虚拟机提供服务的单元时，将来可能会导致扩展问题。

还有一个误解，即所有客户机系统定义的vCPU的数量应少于HOST系统中可用的CPU的总数。为了进一步扩展这种思想，如果 HOST系统中可用的CPU总数为32，则有些人认为，如果 他们在系统中定义了四个guest 虚拟机，则每个人只能定义八个vCPU 。没有这样的规则。通常，这些vCPU是在KVM主机中运行的轻量级进程，这些进程由Linux调度程序根据当前制定的调度策略进行调度，这应该以公平的方式对待系统中运行的所有进程。

也就是说，KVM支持过量使用虚拟化CPU。在此必须应用的规则是，在客户机虚拟机的负载限制允许的范围内，虚拟化CPU可能会被过量使用。但是，此处必须特别注意，否则如果vCPU负载增加到接近 100％，可能会严重损害性能。

**vCPU****数量**

考虑到vCPU分配或过量使用对性能的影响，您应确保为单个系统分配的vCPU（SMP 虚拟机）数量不超过KVM主机中的物理核心总数。例如：如果物理系统具有八个核心，则单个客户机应分配的vCPU不应超过八个。如果这样做，则很有可能会导致性能显着下降。在这种情况下，将8个vCPU分配给单个客户机没有任何问题。这应该按预期工作。如前所述，当客户机系统负载受到限制或小于100％时，这些规则将最适合。关于过度使用CPU的警告：在生产环境中，如果不验证可能发生的最坏情况，则不应过度使用CPU。我们说，当KVM主机中定义的所有客户机系统的vCPU总数大于系统上的主机CPU数量时，CPU过量使用。如果vCPU的总数大于主机CPU的数量，则过多分配一个或多个虚拟机使用的CPU。因此，在生产系统中实施此功能之前，请进行测试。当您尝试过量使用vCPU数量时，客户端实用程序（例如virt-manager）会发出警告（图2）。

例如，在我们的系统中，有四个可用的CPU，因此当我尝试分配四个以上的vCPU时，会收到一条警告，指出**过量使用****vCPU****会损害性能**，如以下屏幕截图所示：

图2：CPU调整窗口

当我们看前面的屏幕快照时，它显示了客户机系统的CPU /处理器配置，其中有四个主要部分：

• vCPU的数量

• 配置

• 拓扑

• 绑定

我们只是介绍了前面几段中的第一段。

让我们继续第二部分：CPU配置。

**CPU****配置**

使用此选项可根据所需的CPU型号选择**CPU****配置类型**。展开列表以查看可用选项，或单击“ **复制主机****CPU****配置****”** 按钮以检测并应用物理主机的CPU模型和配置。选择CPU配置后，将显示CPU的可用功能/指令，并可以 在“ CPU功能”列表中单独启用/禁用这些功能/指令。

图3：CPU配置窗口

根据系统上KVM软件的版本，可用的CPU配置也有所不同。在我的系统（Fedora 22）中，我具有前面列出的（图3）CPU配置。通过此选项，可以灵活地将所需的CPU模型分配给虚拟机。还有一个选项（“ **复制主机****CPU****配置****”**）可以将KVM主机CPU模型和配置复制到客户机。根据所使用的virt-manager版本，您可能会在virt-manager GUI中获得该选项，以单独选择/取消选择所选CPU配置的CPU功能。最佳实践之一是通过手动配置复制主机CPU配置：

图4：主机CPU功能列表

**CPU****拓扑**

CPU调整的第三阶段是CPU拓扑配置，如图5所示。您可以配置虚拟机的插槽，核心和线程数，如下所示：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 5: CPU topology</p> </td> 
  </tr> 
 </tbody> 
</table>

尽管您的环境可能会决定其他要求，但是选择所需数量的插槽（但只有一个内核和一个线程）通常会提供最佳的性能结果，因此建议使用此设置。

**CPU****绑定**

第四个调整选项是vCPU绑定。当涉及到CPU的性能调整部分时，最知名的技术之一就是vCPU绑定。让我们更详细地讨论这个选项。显然，错误的vCPU绑定会严重影响性能，并可能严重影响您的KVM设置。首先，为什么需要绑定？将特定vCPU绑定在物理CPU上的过程可能会增加CPU命中率。每当将vCPU绑定到物理主机CPU或CPU子集时，都必须考虑是否正在使用具有NUMA（**非统一内存访问**）能力的系统。如果系统支持NUMA，则在绑定过程中应格外小心。通过坚持使用系统特定的NUMA拓扑，可以大大提高性能。的**从主机生成****NUMA****配置**选项可帮助我们自动生成对主机有效的绑定配置。但是，如果系统不支持NUMA，则在尝试生成上述配置时，可能会遇到与以下屏幕截图类似的消息：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 6: Generating from the NUMA configuration</p> </td> 
  </tr> 
 </tbody> 
</table>

本章稍后将讨论有关NUMA配置和vCPU调整的更多信息。可以通过以下各节中讨论的方法来确认NUMA可用性。

**numactl****命令**

确认NUMA可用性的第一个选项使用**numactl**命令， 如下所示：

图7：numactl硬件

它仅列出一个节点。即使这传达了NUMA的不可用性， 也可以通过运行以下命令来进一步说明：

**简而言之****$ cat/sys/kernel/debug/sched\_features**

如果系统不支持NUMA，则*不会*列出NUMA标志。如果系统不支持NUMA，**则从主机****NUMA****生成配置**选项将导致错误。

最好的做法是，*如果客户机系统的**vCPU**数量大于运行它的单个**NUMA**节点*，*则不要使用此选项*。即使NUMA可用，vCPU也会绑定到NUMA节点，而不是特定的物理CPU。我们将在本章后面讨论NUMA感知的CPU调整。

到目前为止，我一直使用**CPU Pinning**一词；这只是在vCPU和主机的物理CPU之间设置“亲和力”的过程，这样vCPU将仅在该物理CPU中执行。使用virsh vcpupin命令将vCPU 1：1绑定到物理CPU或物理CPU的子集：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 8: virsh vCPUpin help command output</p> </td> 
  </tr> 
 </tbody> 
</table>

进行vCPU绑定时，有几个最佳实践：

• 如果客户机vCPU的数量大于单个NUMA节点CPU，请不要使用我们前面讨论的默认绑定选项。

• 如果物理CPU分布在不同的NUMA节点上， 则最好创建多个虚拟机，并将每个虚拟机的vCPU绑定到同一NUMA节点中的物理CPU。这是因为访问不同的NUMA节点或在多个NUMA节点上运行会大大降低物理和虚拟任务的性能。

参考：**[https ][https]**：**[//docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization\_Guide/ch25s06.html][https]**[ ][https]了解更多详细信息。

让我们看一下vCPU绑定的步骤：

1. 执行virsh节点信息以收集有关主机CPU配置的详细信息。

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 9: virsh nodeinfo command output</p> </td> 
  </tr> 
 </tbody> 
</table>

2. 下一步是通过执行命令virsh功能并检查标记为**<topology>**的部分来获取CPU拓扑：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 10: virsh capabilities topology</p> </td> 
  </tr> 
 </tbody> 
</table>

图10显示NUMA在此系统中不可用（<cell id ='0'>）。

3. 一旦确定了主机的拓扑，下一步就是开始绑定vCPU。让我们首先使用具有四个vCPU的名为**centos-1**的客户机检查当前的相似性或绑定配置：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 11: virsh vCPUpin info</p> </td> 
  </tr> 
 </tbody> 
</table>

图11中的输出表示客户机vCPU可以运行任何物理CPU（0-3）。我们现在用来绑定vCPU的方法称为**静态**布局，如客户机XML文件所示：

**<vCPU placement ='static'> 4 </vCPU>**

4. 让我们将vCPU 1绑定到主机的CPU 3：

图12：virsh vCPUpin进程

ID为**1**的vCPU 绑定到ID为**3**的物理CPU 。图12中的输出验证正在运行的VM上的vCPU引脚是否成功完成。要了解有关vCPU标记中可用的放置选项的更多信息，请参见：**[http ][http 1]**: **[//libvirt.org/formatdomain.html\#elementsCPUAllocation][http 1]**。

注意**virsh**命令中列出的CPU亲和力和正在运行的客户机的XML转储中的**<cputune>**标记。就像XML标记所说的那样，它位于客户机的CPU调整部分下。也可以为特定vCPU配置一组物理CPU，而不是单个物理CPU。有关vCPU绑定的更多详细信息，请参考**[http://libvirt.org/formatdomain.html\#elementsCPUTuning][http_libvirt.org_formatdomain.html_elementsCPUTuning]**[。][http_libvirt.org_formatdomain.html_elementsCPUTuning]

有几件事要记住。vCPU绑定可以提高性能；但是，这取决于主机配置和系统上的其他设置。确保进行足够的测试并验证设置。

让我们尝试再次更改vCPU绑定：

图13：virsh vCPUpin进程\-2

您也可以使用virsh vcpuinfo来验证绑定。

•  **vcpuinfo**命令的输出如下：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 14: virsh vcpunfo verification</p> </td> 
  </tr> 
 </tbody> 
</table>

• 客户机的virsh dumpxml输出如下所示：

**<vcpu placement ='static'> 4 </vCPU>**

**<cputune>**

**<vcpupin vCPU ='1'CPUset ='2'/>**

**<vcpupin vCPU ='2'CPUset ='3'/>**

**<vcpupin vCPU ='3'CPUset ='1'/>**

**<vcpupin vCPU ='0'CPUset ='3'/>**

**</cputune>**

称为**emulatorpin****的**另一个属性可以是**<** **cpu** **tune>**元素的子属性。在讨论NUMA时，我们将详细讨论**emulatorpin**。

现在让我们探索内存调整选项。

**处理内存**

内存是大多数环境中的宝贵资源，不是吗？因此，应通过对其进行调整来实现内存的有效利用。优化KVM内存性能的第一条规则是，在设置过程中不会向客户机分配更多的资源！

我们将更详细地讨论以下内容：

• 内存分配

• 内存调优

• 内存支持

**内存分配**

让我们从如何为虚拟系统或客户机分配内存开始。为了简化分配过程，我们将再次考虑libvirt客户端virt-manager。可以从以下屏幕快照所示的窗口中进行内存分配。

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 15: Memory allocation window</p> </td> 
  </tr> 
 </tbody> 
</table>

如上图所示，有两个主要选项：**当前分配**和**最大分配**：

•  **最大分配**：客户机的运行时最大内存分配。这是客户机运行时可以分配给客户机的最大内存

•  **当前分配**：客户机的实际内存分配。该值可以小于最大分配，以允许迅速增加客户机的内存

**--snip-- from http://libvirt.org/formatdomain. html\#elementsMemoryAllocation <domain> ...**

**<maxMemory slots='16' unit='KiB'>1524288</maxMemory>**

**<memory unit='KiB'>524288</memory>**

**<currentMemory unit='KiB'>524288</currentMemory> ...**

**</domain>**

所述**的****virsh**命令可以用来调整这些参数或配置。相关的**virsh**命令是**setmem**和**setmaxmem**。以下屏幕截图显示了命令选项和参数说明：

图16：virsh setmem/setmaxmem选项

如果存在NUMA，则内存调整过程可能会有些棘手。我们将在NUMA部分对此进行讨论。

**内存调优**

内存调整选项添加在客户机配置文件的**<memtune>**下。

内存调整的客户机XML表示可以表示如下：

**<domain> ...**

**<memtune>**

**<hard\_limit unit='G'>1</hard\_limit>**

**<soft\_limit unit='M'>128</soft\_limit>**

**<swap\_hard\_limit unit='G'>2</swap\_hard\_limit>**

**<min\_guarantee unit='bytes'>67108864</min\_guarantee>**

**</memtune>**  **...**

**</domain>**

请参阅**[http://libvirt.org/formatdomain。 ][http_libvirt.org_formatdomain_][html\#elementsMemoryTuning][http_libvirt.org_formatdomain_]** 以获得更多详细信息。

virt管理员可以手动配置客户机的内存设置。如果省略**<memtune>**配置，则默认内存设置适用于虚拟机。这里正在播放的virsh命令是：

**\#virsh memtune <****虚拟机****>-****参数大小**

**参数**可以具有以下任何值；手册页中充分记录了这种最佳实践：

**--snip-****来自****virsh****手册页**

**--hard-limit** **客户机可以使用的最大内存。**

**--soft-limit** **内存争用期间要强制执行的内存限制。**

**--swap-hard-limit** **客户机可以使用的最大内存加上交换。****该值必须大于提供的硬限制值。****--min-guarantee** **为客户机保证的最小内存分配。**

**-/****snip** **-**

可以获取为**memtune**参数设置的默认/当前值，如下所示：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 17: virsh memtune value listing</p> </td> 
  </tr> 
 </tbody> 
</table>

如同手册页中所述：

*“**对于**QEMU/KVM**，参数作为一个整体应用于**QEMU**进程。因此，在对它们进行计数时，需要累加客户机**RAM**，客户机视频**RAM**和**QEMU**本身的一些内存开销。最后一件很难确定，以便需要猜测和尝试。对于每个可调参数，可以使用与**<memory>**相同的值来指定数字在输入中的单位。为了向后兼容，输出始终在**KiB**中。*

设置**hard\_limit****时**，不应将此值设置得太低，因为 如果该值太低，客户机/域可能会被内核杀死。确定 进程运行所需的内存是一个不确定的问题。

要了解有关如何设置这些参数的更多信息，请参见以下屏幕快照中**memtune**命令的帮助输出：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Figure 18: virsh memtune help</p> </td> 
  </tr> 
 </tbody> 
</table>

当我们讨论了内存分配和调优后，最后的选择就是 内存支持。

**内存支持**

以下是内存支持的客户机XML表示形式：

**<domain> ...**

**<memoryBacking>**

**<hugepages>**

**<page size="1" unit="G" nodeset="0-3,5"/>**

**<page size="2" unit="M" nodeset="4"/>**

**</hugepages>**

**<nosharepages/>**

**<locked/>**

**</memoryBacking> ...**

**</domain>**

您可能已经注意到，内存备份有三个主要选项：**hugepages**，**nosharepages**和**locked**。

让我们从**锁定**开始一个接一个地研究它们。

**锁定**

如前几章所述，在KVM环境中，客户机内存位于KVM主机中**qemu-kvm**进程的进程地址空间中。Linux内核可以根据主机的要求随时将这些客户机存储器页面换出。**锁定**可以帮助我们！如果将虚拟机的内存备份选项设置为**lock**，则主机将不会换出属于虚拟系统或虚拟机的内存页面。启用此选项后，主机系统内存中的虚拟内存页面将被锁定：

**<memoryBacking>**

**<locked/>**

**</memoryBacking>**

需要注意的是，当设置**锁定**，一个**hard\_limit**必须在设置**<memtune>**元件被配置为客户机最大存储器，加上由过程本身所消耗的任何存储器。

**无共享页面**

以下是客户机配置文件中nosharepages的XML表示形式：

**<memoryBacking>**

**<nosharepages />**

**</memoryBacking>**

当内存页相同时，可以使用不同的机制来共享内存。诸如KSM（内核同一页面合并）之类的技术在客户机系统之间共享页面。该**nosharepages**选项指示系统管理程序禁用为此客户机共享的页面。即，设置**nosharepages** 可以防止主机合并客户机之间使用的相同内存。

**大页面**

第三个也是最后一个选择是大**页面**；可以用XML格式表示， 如下所示：

**<memoryBacking>**

**</hugepages>**

**</memoryBacking>**

在Linux内核中引入了Hugepages，以提高内存管理的性能。内存以称为**页面的**块进行管理。不同的体系结构（i386，ia64）支持不同的页面大小。x86 CPU通常以4 KB页面寻址内存，但是它们能够使用2 MB到1 GB的较大页面，称为**hugepages**。CPU具有内置的**内存管理单元**（**MMU**），其中包含这些页面的列表。通过页面表引用页面，并且每个页面在页面表中都有一个引用。当系统要处理大量内存时，主要有两种选择。其中之一涉及增加硬件MMU中页表条目的数量。第二种方法增加默认页面大小。如果我们选择增加页表条目的第一种方法，那确实很昂贵。现代处理器中的硬件MMU仅支持数百或数千个页面表条目，并且在处理大量页面表条目或基于大量条目的操作时会遇到困难。

有大量的内存管理打交道时，第二个也是更有效的方法是*大页面*或增加页面大小。2 MB页面使用的页表适用于管理多个GB的内存，而1 GB页面的页表最适合于扩展到TB的内存。大页面可以显着提高性能，特别是对于占用大量内存的工作负载而言。大多数已知的Linux发行版都可以通过使用大页面来增加页面大小，从而更有效地管理大量内存。进程可以使用大页内存支持来提高性能，方法是增加CPU对**翻译后备缓冲区**（**TLB****）的命中率**）。您已经知道客户机系统只是Linux系统中的进程，因此KVM客户机有资格执行相同的操作。

**TLB**是用于虚拟到物理地址的转换的高速缓存。通常，这是处理器上非常稀缺的资源。操作系统试图充分利用有限数量的TLB资源。由于越来越容易获得越来越大的物理内存（几个GB），因此这种优化现在变得尤为重要。

前面提到的用于大页面的XML条目指示虚拟机管理程序，客户机应该使用大页面而不是正常的本机页面大小来分配其内存。如果系统支持NUMA，则最新版本的libvirt可以专门为每个NUMA节点设置拥抱页面。所述**<****页面****>**元件由引入的libvirt以满足这一点。它具有一个强制性属性'size'，该属性指定应使用大页面（在支持不同大小的大页面的系统上特别有用）。稍后，当我们在支持NUMA的系统中讨论CPU和内存调整时，将对此进行详细讨论。

在继续之前，我们还应该提到**透明大页面**（**THP**）。 THP是一个抽象层，可 根据应用程序请求自动分配巨大的页面大小。

透明的Hugepage支持可以完全禁用，或者只能在**MADV\_HUGEPAGE**区域内启用（以避免消耗更多内存资源的风险），或者在整个系统范围内启用。在系统中配置THP的方法有以下三个主要选项：**always**，**madvise**和**never**：

THP in a system: **always**, **madvise**, and **never**:

**\# cat/sys/kernel/mm/transparent\_hugepage/enabled**

**always \[madvise\] never**

**\#**

从上面的输出中，我们可以看到我系统中当前的THP设置是**madvise**。可以通过以下方法启用其他选项：

**echo always >/sys/kernel/mm/transparent\_hugepage/enabled**

**echo madvise >/sys/kernel/mm/transparent\_hugepage/enabled**

**echo never >/sys/kernel/mm/transparent\_hugepage/enabled**

简而言之，可以将这些值的启用值设置为：

•  **always**：始终使用THP

•  **madvise**：仅在标有**MADV\_HUGEPAGE****的**虚拟内存区域（VMA）中使用大**页面**

•  **never**：禁用此功能

THP会自动优化性能的系统设置。通过允许所有可用内存用作高速缓存，可以提高性能。当THP就位时，可以使用静态大页面，否则THP不会阻止使用静态方法。但是，当不使用静态大页面时，KVM将使用透明大页面，而不是常规的4 Kb页面大小。通过为KVM客户机的内存使用大页面而获得的优势在于，用于页面表的内存更少，并且减少了TLB丢失。显然，这可以提高性能。但是请记住，将大页面用于客户机内存时，您将无法再交换或增加客户机内存。

让我们快速了解如何在您的KVM设置中使用静态大页面：

在上面的屏幕截图中，我们可以看到该系统中的大页面大小为2 MB。

1. 通过运行以下命令或从**sysfs****中**获取当前的巨页值**，**如下所示：

**\# cat/proc/sys/vm/nr\_hugepages**

**0**

**\#**

2. 在**sysfs****中，**使用**sysctl -a |grep huge**命令：

3. 由于此处的大页面大小为2 MB，因此我们可以2 MB为增量设置大页面。要将大页面数设置为26,000，请使用以下命令：

**\# echo 26000>/proc/sys/vm/nr\_hugepages**

分配给大页面的总内存不能由不支持大页面的应用程序使用。即，如果您过多分配大型页面，则主机系统的正常功能可能会受到影响。

4. 要使其持久，可以使用以下命令：

**\# sysctl -w vm.nr\_hugepages = <****大页面数****>**

5. 然后，挂载大页面并重新启动libvirtd服务：

**\# mount -t hugetlbfs hugetlbfs/dev/hugepages**

**\#** **sysctl start libvirtd**

6. 重新启动配置了巨大页面的客户机（**<memoryBacking> </hugepages> </memoryBacking>****）**。VM现在将开始使用大页面。使用主机上的**cat /proc/meminfo |grep -i huge**命令来验证这一点。

**了解内核相同页合并**

根据KVM官方文档：

*KSM**是节省内存的重复数据删除功能，可合并匿名（专用）页面（而非页面缓存页面）。尽管**KSM**是以这种方式开始的，但它目前不仅适用于虚拟机，还适用于**KSM**，因为它对于生成同一数据的许多实例的任何应用程序都非常有用。*

**[http://www.Linux-kvm.org/page/KSM][http_www.Linux-kvm.org_page_KSM]**

从前面的引用中可以很好地理解，KSM是一项允许在系统中运行的不同进程之间共享相同页面的功能。我们可以假定由于某些原因（例如，如果从同一二进制文件或类似内容衍生出多个进程），可能存在相同的页面。虽然没有这样的规则。KSM扫描这些相同的内存页面，并合并**写时复制（****COW**）共享页面。好吧，如果您不了解我所说的COW，那无非是一种机制，当试图更改一个以上进程共享和共有的内存区域时，请求更改的进程获取新副本并将更改保存在其中。此处同样适用。即使所有进程都可以访问合并的COW共享页面，但是只要某个进程尝试更改内容（此处是对页面的写操作），该进程都会获得包含更改的新副本。到目前为止，您已经了解到，通过使用KSM，我们可以减少物理内存的消耗。在KVM上下文中，这确实可以增加价值，因为客户机系统是系统中的qemu-kvm进程，并且所有VM进程都有大量相似内存的可能性很大。

为了使KSM工作，进程/应用程序必须在KSM中注册其内存页。在KVM领域，KSM允许客户机共享相同的内存页面，从而改善了内存消耗。大多数共享页面通常是公共库或其他相同的高使用率数据。该共享页或内存被标记为“写入时复制”。简而言之，KSM避免了内存重复，当 KVM环境中存在类似的客户机操作系统时，它非常有用。

从前面的理论来看，很明显，KSM提供了增强的内存速度和利用率。通常，此公共共享数据存储在缓存或主内存中，这会减少KVM 虚拟机的缓存丢失。此外，KSM可以减少客户机的总体内存占用，因此，以一种方式，它允许用户在KVM设置中进行内存过量使用，从而提供了更多 的可用资源利用率。但是，我们必须记住，KSM需要 更多的CPU资源来识别重复的页面并执行诸如共享/合并之类的任务。

之前，我提到过，这些流程必须标记“页面”以表明它们是KSM运营的合格候选人。可以通过基于**MADV\_MERGEABLE**标志 的过程来完成标记，我们将在下一部分中进行讨论。您可以从**madvise**手册页中探索此标志的用法：

**--snip-** **来自****\#man 2 madvise**

*MADV\_MERGEABLE**（从**Linux 2.6.32**开始）*

*在**addr**和**length**指定的范围内，为页面启用内核同一页面合并（**KSM**）。内核会定期扫描那些已标记为可合并的用户内存区域，以查找内容相同的页面。**这些将被单个写保护页面替换（如果某个进程以后想要更新页面内容，则会自动复制该页面）。* *KSM**仅合并私有匿名页面（请参阅**mmap**（**2**））。*

*KSM**功能旨在用于生成相同数据的许多实例的应用程序（例如，虚拟化系统，例如**KVM**）。**它会消耗大量的处理**能力；小心使用。**有关更多详细信息，请参见**Linux**内核源文件**Documentation/vm/ksm.txt**。*

*仅当内核配置有**CONFIG\_KSM**时，**MADV\_MERGEABLE**和**MADV\_UNMERGEABLE**操作才可用。*

因此，必须使用KSM配置内核，例如：

为了进一步探索KSM，我们将讨论可用的软件包和配置KSM的选项。

**KSM****软件包和文件**

Fedora 22中的KSM软件包提供以下文件。服务配置文件和二进制文件（如**ksmctl**和**ksmtuned****）**也是此软件包的一部分：

可以从**sysfs**文件系统中获取有关KSM服务的信息。

该位置有不同的文件可用，反映了当前KSM的状态。这些由内核动态更新，并且具有KSM使用情况和统计信息的精确记录：

在下一部分中，我们将讨论**ksmtuned**服务及其配置变量。由于**ksmtuned**是控制KSM的服务，因此它的配置变量类似于我们在**sysfs**文件系统中看到的文件。我们将在此处列出**sysfs****中**存在的文件，并**简要**说明每个文件的含义：

•  **full\_scans**：运行完整扫描

•  **merge\_across\_nodes**：是否 可以合并来自不同NUMA节点的页面

•  **pages\_shared**：共享的页面总数

•  **pages\_sharing**：当前共享的页面

•  **pages\_to\_scan**：未扫描的页面

•  **pages\_unshared**：页面不再共享

•  **pages\_volatile**：易失性页面数

•  **运行**：KSM进程是否正在运行

•  **sleep\_millisecs**：睡眠毫秒

也可以使用灵活的**virsh**命令调整这些参数。该**的****virsh****节点内存调整**命令来完成这个工作适合你。例如，以下指定共享内存服务进入睡眠之前要扫描的页面数：

**\#virsh node-memory-tune --shm-pages-to-scan number**

与其他任何服务一样，**ksmtuned**服务还具有存储在日志文件 **/var/log/ksmtuned****中的日志**。如果在**/etc/ksmtuned.conf**文件中添加了**DEBUG = 1** 行，则KSM调整活动将存储在此日志文件中。

有关更多详细信息，请参阅**[https://www.kernel.org/doc/Documentation/vm/ksm.txt][https_www.kernel.org_doc_Documentation_vm_ksm.txt]**。

如下图所示，一旦启动了KSM服务，您就可以观察到值根据实际使用的KSM服务而被更改：

**\#systemctl****启动****ksm**

KSM服务启动了一个名为**ksmd**的内核线程，**如此**处所示：

图23：ksm service命令和ps命令输出

一旦启动KSM服务，请通过查询**sysfs**观察更改，如图24所示。当KSM处于活动状态时，您可以看到其中一些值被更改：

让我们更详细地探索**ksmtuned**服务。该 **ksmtuned**服务的设计，它经过的行动周期和调整KSM这样一种方式; 这个动作周期将继续循环。每当创建或销毁客户机系统时，libvirt都会通知**ksmtuned**服务。

该**/etc/ksmtuned.conf**文件是配置文件**ksmtuned**服务。 以下文件输出是默认的**ksmtuned.conf**文件：

这是可用配置参数的简要说明。您可以在**sysfs****中**看到这些配置参数与KSM文件匹配：

**\#ksmtuned****的配置文件。**

**\#****在调整调整之间****ksmtuned****应该睡眠多长时间**

**\#KSM\_MONITOR\_INTERVAL = 60**

**\#****在****ksm****扫描之间对****16Gb****服务器的睡眠时间为毫秒。**

**\#****较小的服务器睡眠更多，较大的睡眠更少。**

**\#KSM\_SLEEP\_MSEC = 10**

**\#KSM\_NPAGES\_BOOST-****当****“****可用内存****”****小于****“****三****”****时被添加到****“ npages”****值中。****\#KSM\_NPAGES\_BOOST = 300**

**\#KSM\_NPAGES\_DECAY-****是当****“****可用内存****”****大于****“****阈值****”****时，****将给定的值减去****“ npages”****值。****\#KSM\_NPAGES\_DECAY = -50**

**\#KSM\_NPAGES\_MIN-****是****npages****值的下限。**

**\#KSM\_NPAGES\_MIN = 64**

**\#KSM\_NPAGES\_MAX-****是****\`npages\`****值的上限。**

**\#KSM\_NPAGES\_MAX = 1250**

**\#KSM\_THRES\_COEF-****是要在参数****\`thres'****中计算的****RAM****百分比。**

**\#KSM\_THRES\_COEF = 20**

**\#KSM\_THRES\_CONST-****如果这是一个内存不足的系统，并且****thres****值小于****KSM\_THRES\_CONST****，则将****thres****值重置为**

**KSM\_THRES\_CONST****值。**

**\#KSM\_THRES\_CONST = 2048**

**/etc/ksmtuned.conf**文件中的这些配置参数指示KSM操作。例如，**npages**设置**ksmd**进入睡眠状态之前KSM将扫描多少页。它将设置在**/sys/kernel/mm/ksm/pages\_to\_scan**。**thres**设置激活阈值（以千字节为单位）。当RSZ超过系统总内存时，将**thres**值添加到所有qemu-kvm进程的总和中时，将触发KSM周期。此参数等效于**KSM\_THRES\_COEF**参数中定义的百分比的**千**字节。

好吧，KSM旨在提高性能并允许内存过量使用。它在大多数环境中都可以达到这个目的。但是，KSM可能会在某些设置或环境中引入性能开销。另外，还有一个担忧，即KSM可能会打开一个通道，该通道可能会被用来泄露客户机之间的信息。如果您有这些问题，或者您看到/体验了KSM不能帮助您提高工作负载的性能，则可以禁用KSM。

要禁用KSM，请通过执行以下**命令**在系统中停止**ksmtuned**和**ksm**服务：

**\#systemctl stop ksm**

**\#systemctl****停止****ksmtuned**

到现在为止，我们已经经历了**CPU**和 **内存的**不同调整选项。我们已经介绍了可用的选项及其基本用法。但是，我们应该继续在支持NUMA的系统中推动CPU和内存调整。即使我们之前谈到了针对CPU和内存的NUMA调整，我们还是跳过了一些功能。让我们现在覆盖它们。

**使用****NUMA****调整****CPU****和内存**

在开始为支持NUMA的系统调整CPU和内存之前，让我们先看看NUMA是什么以及它如何工作。

**什么是****NUMA****？**

NUMA **是非统一内存访问**的缩写：

图25：来自维基百科的参考

将NUMA视为一个系统，其中有多个系统总线，每个系统总线都服务于一小组处理器和相关的内存。每组处理器都有自己的内存，可能还有自己的I/O通道。可能无法 停止或阻止跨这些组的访问。这些组中的每一个都称为

NUMA节点。

在此概念中，如果进程/线程在NUMA节点上运行，则通常将同一节点上的内存称为本地内存，并将驻留在另一个节点上的内存称为外部/远程内存。此实现不同于**SMP** （**对称多处理器系统**），在**SMP****中**，所有内存的访问时间对于所有CPU都是相同的。

存在一种称为NUMA的比率，它衡量的是CPU访问本地内存的速度与访问远程/外部内存的速度之比。例如，如果NUMA比率为2.0，则访问远程内存所需的时间是CPU的两倍。如果NUMA比为1，则它是对称多处理（SMP）。该比率越大，访问其他节点的内存的成本就越高。在更深入地研究调优之前，让我们讨论探索系统的NUMA拓扑。显示当前NUMA拓扑的最简单方法之一是通过**numactl**命令：

图26：numactl输出

上面的numactl输出表明，系统中有32个CPU，它们属于两个NUMA节点。它还列出了与每个NUMA节点关联的内存和节点距离。当我们讨论vCPU绑定时，我们使用**virsh**功能显示了系统的拓扑。该命令可以提供更多详细信息，如下所示：

图27：系统的NUMA拓扑

要获得NUMA拓扑的图形视图（请参考下图），可以使用称为**lstopo**的命令**，**该命令在基于Red Hat的系统中与**hwloc-gui**软件包一起提供：

图28：istopo命令可视化NUMA拓扑

此屏幕快照还显示了与NUMA节点关联的PCI设备。例如，**em \***（网络接口）设备连接到NUMA节点0。一旦我们有了系统的NUMA拓扑并了解了它，就可以开始对其进行调整，尤其是针对KVM虚拟化设置。

**NUMA****内存分配策略**

NUMA调整的XML表示如下。您可以看到，调优NUMA引入了一个名为**numatune**的新元素标签：

**<****域****> ...**

**<numatune>**

**<****内存模式****=“ strict” nodeset =“ 1-4****，****^ 3” />**

**</numatune> ...**

**</domain>**

也可以通过**virsh**命令进行配置，如下所示：

**Numatune**

该标签的XML表示可以显示如下：

**<****域****>**

**…**

**<numatune>**

**<****内存模式****=“ strict” nodeset =“ 1-4****，****^ 3” />**

**<memnode cellid =“ 0” mode =“ strict” nodeset =“ 1” />**

**<memnode cellid =“ 2” mode =“ preferred” nodeset =“ 2” />**

**</numatune> ...**

**</domain>**

即使称为**numatune**的元素是可选的，也可以通过控制域进程的NUMA策略来提供它来调整NUMA主机的性能。此可选元素的主要子标签是**memory**和**nodeset**。 这些子标记的一些注意事项如下：

• 内存：可选的**内存**元素指定如何为NUMA主机上的域进程分配内存。它包含几个可选属性。属性模式是**交错**，**严格**或**首选** ; 默认 是**严格的**。

三种策略类型定义了如何从 系统中的节点分配内存：

° 严格：如果无法在目标节点上分配内存，则默认操作是将分配回退到其他NUMA节点。在**严格的**政策意味着，如果该内存不能在目标节点上分配的分配也会失败。

° 交错：内存页在**nodemask**指定的节点之间分配，但以循环方式分配。

° 首选：从单个首选内存节点分配内存。如果没有足够的内存，则可以从其他节点分配内存。

• nodeset：**nodeset**属性使用与vCPU元素的**cpuset**属性相同的语法指定NUMA个节点。**nodeset**是主机用于运行域的NUMA节点的列表。它的语法是逗号分隔的列表，其中**-**表示范围，**^**表示排除节点。

此处的重要属性之一是**放置**：

*“**属性放置可用于指示域进程的内存放置模式，其值可以是**“ static”**或**“ auto”**，默认为**vCPU**的放置，如果指定了节点集，则其值为**“ static”**。**“ auto”**指示域进程将仅从查询**numad**返回的咨询节点集中分配内存，并且如果指定了属性**nodeset**的值，则将忽略该属性。如果**vCPU**的位置为**'auto'**，并且未指定**numatune**，则默认的**numatune**及其位置*

*“ auto”**和**mode“ strict”**将被隐式添加。**”*

参考：**[http][http 2]** : **[//libvirt.org/formatdomain.html\#elementsNUMATuning][http 2]**[。][http 2]

如果我们扩展前面的字符串，或者如果我们总结了这些层次结构，我们将得出以下摘要：

在**<vcpu>**和**<numatune>****所**使用的**放置**模式之间存在隐式继承规则：

• 用于放置模式**<numatune>**默认为相同的放置模式为**<VCPU>**或**静态**如果**<****节点集****>**被指定

• 类似地，对于放置模式**<VCPU>**默认为相同的放置模式为**<numatune>**或**静态**如果**<cpuset>**被指定

这意味着可以分别指定和定义域进程的CPU调整和内存调整，但也可以将它们配置为依赖 于另一个的放置模式。

在NUMA上下文中考虑vCPU绑定时，还需要考虑其他事项。我们在本章前面讨论了vCPU绑定的基础。简而言之，它为绑定在裸机系统上的任务提供了类似的优势。它提高了缓存效率。这样的一个示例是一种环境，其中所有vCPU线程都在同一物理插槽上运行，因此共享一个L3缓存域。在讨论vCPU绑定时，我们说应该在存在NUMA时解决一些基本的调整问题，因为将vCPU绑定与**numatune**结合可以避免NUMA **遗漏**。NUMA丢失对性能的影响很大，通常从10％或更高的性能命中率开始。vCPU绑定和**Numatune**应该一起配置。作为一个用例，如果虚拟机正在执行存储或网络I/O任务，则将所有vCPU和内存绑定到物理连接到I/O适配器的同一物理插槽上可能会有所帮助。

**仿真器引脚**

我们指出**emualtorpin**可以属于CPU调整元素。其XML表示形式如下：

**<****域****> ...**

**<cputune> …..**

**<emulatorpin cpuset =“ 1-3” /> …..**

**</cputune> ...**

**</domain>**

所述**emulatorpin**元件是可选的，用于对仿真器（QEMU的KVM）端子到主机物理CPU。这不包括来自VM的vCPU或IO线程。它包含一个必需的属性CPU集，用于指定要绑定到的物理CPU。所述**<emulatorpin>**标签提供了一种设置一个精确的亲和力仿真器线程处理的方法。结果，在物理CPU和内存的同一子集上运行的虚拟主机线程将受益于缓存局部性。如果省略此选项， 则默认情况下将**仿真器**绑定到主机系统的所有物理CPU。

请注意，在**调试支持** NUMA的系统时，应一起配置**<vcpupin>**， **<numatune>**和**<emulatorpin>**以获得最佳的确定性性能。在离开本节之前，我们还要介绍两件事：客户机系统NUMA拓扑和NUMA支持的大页内存。

客户机NUMA拓扑可以使用客户机XML配置中的**<numa>**元素指定；有人称其为虚拟NUMA：

**<CPU> ...**

**<numa>**

**<cell id ='0'CPUs ='0-3'memory ='512000'unit ='KiB'/>**

**<cell id ='1'CPUs ='4-7'memory ='512000'unit ='KiB'memaccess ='shared'/> </numa> ...**

**</CPU>**

客户机NUMA拓扑可以使用客户机虚拟机XML 的**<cpu>**标记内的**<numa>**标记指定。每个单元元素都指定一个NUMA单元或NUMA节点。所述**<****的****CPU>**标记指定是节点的一部分的CPU的CPU或范围。内存以千字节（即1,024字节的块）为单位指定节点内存。同样，可选属性**memaccess**可以控制将内存映射为“共享”还是“私有”。这仅对大页面支持的内存有效。每个单元或节点从0开始按递增顺序分配一个单元ID或节点ID。

之前，我们讨论了**memorybacking**元素，可以将其指定为在客户机配置中使用大页面。当安装程序中存在NUMA时，可选的**nodeset**属性可能会派上用场，因为它将给定客户机的NUMA节点与某些大页面大小相关联：

**<memoryBacking>**

**<****大页****>**

**<page size =“ 1” unit =“ G” nodeset =“ 0-3,5” />**

**<page size =“ 2” unit =“ M” nodeset =“ 4” />**

**</hugepages>**

**</memoryBacking>**

简单来说，可以使用前面的配置将来自主机的大页面分配给多个客户机NUMA节点。引入<page>元素以满足要求。它具有一个强制性的属性**大小**，该**大小**指定应使用大页面（在支持不同大小的大页面的系统上特别有用）。size属性的默认单位是千字节（1,024的乘数）。如果要使用其他单位，请使用可选的**unit**属性。这可以优化内存性能，因为可以根据需要将客户机NUMA节点移动到主机NUMA节点，而客户机可以继续使用主机分配的大页。

NUMA调整还必须考虑PCI设备的NUMA节点局部性，尤其是当PCI设备从主机传递到客户机时。 如果相关的PCI设备隶属于远程numa节点，则这可能会影响数据传输并因此损害性能。

显示NUMA拓扑和PCI设备从属关系的最简单方法是 使用我们前面讨论的**istop**命令。 同一命令的非图形形式也可用于发现此配置。请参考 前面的部分。

**KSM****和****NUMA**

在前面的部分中，我们对KSM进行了足够详细的讨论。KSM能够检测系统正在使用NUMA内存并控制不同NUMA节点之间的合并页面。如果您还记得的话，当我们从**sysfs****中**获取KSM条目时，我们遇到了一个名为**merge\_across\_node**的**sysfs**条目。我们可以使用此参数来控制属于不同NUMA节点的页面的合并。

**\[humble-numaserver\] $ cat/sys/kernel/mm/ksm/merge\_across\_nodes**

**1****个**

**\[****卑鄙的****numaserver\] $**

默认情况下，所有节点的页面都可以合并在一起。当此参数设置为零时，仅合并来自同一节点的页面。

通常，除非您过量订阅或过量使用系统内存，否则通过禁用KSM共享将获得更好的运行时性能。

当KSM在具有多个客户机虚拟机的NUMA主机上的节点之间进行合并时，来自较远节点的客户机和CPU可能会大大 增加对合并的KSM页面的访问延迟。

显然，您知道客户机XML条目（**memorybacking**元素），用于要求管理程序禁用客户机的共享页面。如果您不记得了，请阅读内存调整部分，以了解此元素的详细信息。即使我们可以手动配置NUMA，也存在称为自动NUMA平衡的功能。我们之前提到过。让我们看看这个概念涉及什么。

**自动****NUMA****平衡**

自动NUMA平衡的主要目的是提高在支持NUMA的系统中运行的不同应用程序的性能。设计背后的策略很简单：当应用程序的进程线程正在访问由内核调度线程的同一NUMA节点上的内存时，应用程序通常将表现最佳。自动NUMA平衡使任务（线程或进程）更靠近它们正在访问的内存。它还会将应用程序数据移到内存中，使其更靠近引用它的任务。当自动NUMA平衡处于活动状态时，这全部由内核自动完成。在具有NUMA属性的硬件上启动时，将启用自动NUMA平衡。主要条件或标准是：

•  **numactl --hardware**：显示多个节点

•  **cat/sys/kernel/debug/sched\_features**：在标志中显示NUMA

为了说明第二点：

**\[humble-numaserver\] $ cat/sys/kernel/debug/sched\_features**

**GENTLE\_FAIR\_SLEEPERS START\_DEBIT NO\_NEXT\_BUDDY LAST\_BUDDY CACHE\_HOT\_BUDDY**

**WAKEUP\_PREEMPTION ARCH\_POWER NO\_HRTICK NO\_DOUBLE\_TICK LB\_BIAS NONTASK\_**

**电源****TTWU\_QUEUE NO\_FORCE\_SD\_OVERLAP RT\_RUNTIME\_SHARE NO\_LB\_MIN NUMA**

**NUMA\_FAVOUR\_HIGHER NO\_NUMA\_RESIST\_LOWER**

我们可以通过以下方法检查是否在系统中启用了它：

**\[humble-numaserver\] $ cat/proc/sys/kernel/numa\_balancing**

**1****个**

**\[****卑鄙的****numaserver\] $**

显然，我们可以通过以下方式禁用自动NUMA平衡

**\#****回声****0>/proc/sys/kernel/numa\_balancing**

自动NUMA平衡机制根据 算法和数据结构的数量来工作。此方法的内部原理基于 以下内容：

• NUMA提示页面错误

• NUMA页面迁移

• 任务分组

• 故障统计

• 任务放置

• 伪交织，依此类推

有关更多详细信息，请参阅：**[http：//events。][http_events]**

**[Linuxfoundation.org/sites/events/files/slides/][http_events][summit2014\_riel\_chegu\_w\_0340\_automatic\_numa\_ ][http_events][balancing\_0.pdf][http_events]**

这些概念的任何进一步解释都超出了本书的范围。前面的演示提供了有关如何应用这些参数和性能基准测试的详细信息。请注意，手动对应用程序进行NUMA调整将覆盖自动NUMA平衡，从而禁用这些应用程序的定期内存取消映射，NUMA故障，迁移和自动NUMA放置。同样，在某些情况下，系统范围内的手动NUMA调整是首选。

对于KVM客户机，最佳实践或建议之一是将其 资源限制为单个NUMA节点上的资源量。简而言之， 这避免了在NUMA节点之间不必要地分配资源，这 会降低性能。

**了解****numad****和****numastat**

有一个守护程序来控制具有以下功能的系统上的CPU和内存的有效使用：

NUMA拓扑。**numad**被称为自动NUMA相似性管理守护程序。它监视系统中的NUMA拓扑和资源使用情况，以动态改善NUMA资源分配和管理。

*numad**是一个用户级守护程序，它提供放置建议和过程管理，以在具有**NUMA**拓扑的系统上有效使用**CPU**和内存。*

*Numad**是一个系统守护程序，用于监视**NUMA**拓扑和资源使用情况。它将尝试定位进程以实现有效的**NUMA**局部性和亲和力，并动态调整以适应不断变化的系统条件。**Numad**还提供指导，以协助管理应用程序对其进程进行**CPU**和内存资源的初始手动绑定。请注意，**numad**主要用于服务器整合环境，在该环境中，可能在同一服务器系统上运行多个应用程序或多个虚拟客户机。当进程可以定位在系统**NUMA**节点的子集中时，**Numad**最有可能产生积极影响。例如，如果整个系统专用于大型内存数据库应用程序，尤其是如果内存访问可能仍然无法预测，那么**numad**可能不会提高性能。*

请记住，启用**numad**时，其行为将覆盖自动NUMA平衡的默认行为。要根据NUMA拓扑自动调整和对齐CPU和内存资源，我们需要运行**numad**。要将**numad**用作可执行文件，只需运行：

**\#numad**

您可以检查是否已启动，如下所示：

**\[humble-numaserver\] $ ps aux | grep numad**

**根** **9170 0.0 0.0 93596 2828 Ssl Nov17 06:49 numad**

一旦执行了**numad**二进制文件，它将开始对齐，如下所示。在我的系统中，正在运行以下虚拟机。

**\[humble-numaserver\] $ virsh****列表**

**ID** **名称****状态**

**-------------------------------------------------- -**

**12 rhel7.0** **运行**

**17****个** **rhel7-atomic3** **运行**

**运行****19****个** **rhel7-atomic2**

**正在运行****20****个** **rhel7-atomic1**

**24****fedora21** **正在运行**

**25****rhel7.0-2** **运行**

如果您在**/var/log/numad**日志文件中观看**numad**操作，则可以看到类似的消息！

**2015****年****11****月****17****日星期二****06:49:43****：将****/sys/kernel/mm/transparent\_hugepage/khugepaged/scan\_sleep\_millisecs****中的****THP****扫描时间从****10000****更改为****1000 ms****。****2015****年****11****月****17****日星期二****06:49:43****：注册****numad****版本****20140225 PID 9170**

**2015****年****11****月****17****日星期二****06:49:45****：建议****pid 1479****（****qemu-kvm****）从节点移动**

**（****0-1****）到节点（****1****）**

**2015****年****11****月****17****日星期二****06:49:47****：包括****PID****：****1479****在****CPUset****：****/sys/fs/cgroup /**

**CPUset/machine.slice/machine-qemu \\ x2dfedora21.scope/emulator**

**2015****年****11****月****17****日星期二****06****：****49****：****48****：****PID 1479****在****3.33****秒内移至节点****1**

**2015****年****11****月****17****日星期二****06:49:53****：建议****pid 20129****（****qemu-kvm****）从节点转移**

**（****0-1****）到节点（****0****）**

**2015****年****11****月****17****日星期二****06:49:54****：在****CPUset****中包含****PID****：****20129****：****/sys/fs/cgroup /**

**CPUset/machine.slice/machine-qemu \\ x2drhel7 \\ x2datomic3.scope/emulator**

**2015****年****11****月****17****日星期二****06****：****49****：****54****：****PID 20129****在****0.84****秒内移至节点****0**

**2015****年****11****月****17****日星期二****11:03:06****：建议****pid 2194****（****qemu-kvm****）从节点移动**

**（****0-1****）到节点（****0****）**

**2015****年****11****月****17****日星期二****11:03:06****：包括****PID****：****2194****在****CPUset****中：****/sys/fs/cgroup /**

**CPUset/machine.slice/machine-qemu \\ x2drhel7 \\ x2datomic1.scope/emulator 2015****年****11****月****17****日星期二，星期二：****PID 2194****在****0.31****秒内移动到节点****0**

从前面的消息中可以理解，当我们启动二进制文件时，**numad**已执行了一些操作。您可以使用**后续**部分介绍 的**numastat**命令来监视运行**numad**服务之前和之后的**差异**。**numad**将在您的系统中运行，直到使用以下命令停止：

**\#numad -i 0**

请记住，停止**numad**不会删除对提高NUMA亲和力所做的更改。如果系统使用发生重大变化，则在新条件下再次运行 **numad**将调整亲和力以提高性能。现在让我们继续到**numastat**。

“ **numastat-**显示每个NUMA节点的进程和操作系统的内存统计信息”

所述**numactl****的**软件包提供了**numactl****的**二进制/命令和**numad**包提供了**numad**二进制/命令：

图30：qemu-kvm进程的numastat命令输出

在将VM移至生产环境之前，必须使用不同的工作负载对我们使用的多种内存调整选项进行彻底测试。

在继续讨论下一个主题之前，请注意！很难在主机之间实时迁移绑定的客户机，因为在要迁移VM的目标主机或目标主机上可能没有一组相似的支持资源/配置。例如，目标主机可能具有不同的NUMA拓扑。调整KVM环境时，应考虑这一事实。但是，自动NUMA平衡在一定程度上可以帮助手动绑定客户机资源。

**磁盘和块****I/O****调整**

我们将从磁盘选项，传输和镜像格式开始。稍后，我们进行块I/O调整。

VM的虚拟磁盘可以是块设备或镜像文件。

为了获得更好的VM性能，基于块设备的虚拟磁盘比驻留在NFS，GlusterFS等远程文件系统上的镜像文件更为可取。但是，我们不能忽略文件后端有助于virt管理员更好地管理客户机磁盘及其在某些情况下非常有用。根据我们的经验，我们注意到大多数用户都使用磁盘镜像文件，尤其是在性能不是很重要的情况下。请记住，可以连接到VM的虚拟磁盘总数是有限制的。同时，对于混合和使用块设备和文件以及将它们用作同一客户机的存储磁盘没有限制。

如前所述，客户机将虚拟磁盘视为其存储。当客户机操作系统中的应用程序将数据写入客户机系统的本地存储时，它必须经过两层。也就是说，此I/O请求必须遍历存储中的文件系统和客户机操作系统的I/O子系统。之后，qemu-kvm进程将其从客户机OS传递给管理程序。一旦I/O在虚拟机管理程序的保护范围内，它便开始像在主机操作系统中运行的任何其他应用程序一样处理I/O。在这里，您可以看到I/O必须经过数层才能完成I/O。因此，块设备后端的性能要优于镜像文件后端。

以下是我们对磁盘后端以及基于文件或镜像的虚拟磁盘的观察：

• 文件镜像是主机文件系统的一部分，并且与块设备后端相比，它对I/O操作产生了额外的资源需求

• 使用稀疏镜像文件有助于过度分配主机存储，但其使用会降低虚拟磁盘的性能

• 使用磁盘镜像文件时，客户机存储分区不当会导致不必要的I/O操作。这里我们提到的是标准分区单元的对齐方式

在本章开始时，我们讨论了virtio驱动程序，它们提供了更好的性能。因此，建议您在配置磁盘时使用virtio磁盘总线，而不要使用IDE总线。所述**virtio\_blk**驱动程序使用API的Virtio以提供用于存储I/O设备的高性能，因此特别是在大型企业存储系统的存储性能增加。我们在前面的章节中讨论了不同的存储格式。但是，主要格式是**raw**和**qcow**格式。当您使用**原始**格式时，将获得最佳性能。使用**qcow**时，格式层显然会带来性能开销。因为格式层有时需要执行一些操作。例如，如果要增长**qcow**镜像，则必须分配新的群集，依此类推。但是，如果要使用快照等功能，则可以选择**qcow**。镜像格式**qcow**提供了这些额外的功能。可以在**[http://www.Linux-kvm.org/page/Qcow2][http_www.Linux-kvm.org_page_Qcow2]**上找到一些性能比较。

有关**qcow****的**更多详细信息，请参阅**[https://people.gnome.org/~markmc/qcow ][https_people.gnome.org_markmc_qcow][image-][https_people.gnome.org_markmc_qcow] format.html**和**[https://en.wikipedia.org/wiki/Qcow][https_en.wikipedia.org_wiki_Qcow]**。

I/O调整可以考虑三个选项：

• 缓存模式

• I/O模式

• I/O调整

虚拟磁盘配置

**缓存模式**

当我们考虑来自客户机系统的不同缓存设置及其对I/O的影响时，下图很有用：

磁盘缓存模式

以下是不同的缓存模式：

•  **None**：也许您听说过称为**O\_DIRECT**的标志；它允许进程指定执行I/O，而无需使用OS缓存层。该**缓存****=****无**选择是类似于。设置此选项后， 将跳过主机页面缓存，并且I/O直接在 **qemu-kvm****用户空间**缓冲区和基础存储设备之间发生。也就是说 ，来自客户机的I/O不会缓存在主机上，而是可以保留在**回写**磁盘缓存中。对于需要大量I/O的客户机使用此选项。**cache = none**被认为是最佳选择。另外 这是支持迁移的唯一选择。

•  **writethrough**：这与**O\_DSYNC**的语义匹配。来自客户机的I/O缓存在主机上，但直写到物理介质。在这种情况下，仅当数据已提交到存储设备时，才将写入报告为已完成。尽管可以确保数据完整性，但此模式速度较慢并且容易出现扩展问题。但是，如果有少量具有较低I/O要求的客户机，则可以选择此模式。对于不支持**回写**缓存且不需要迁移的客户机，建议使用此缓存模式。

•  **writeback**：在这种情况下，来自客户机的I/O缓存在主机上。使用主机页缓存后，写入主机时将写入完成报告给客户机。正常的页面缓存管理将处理对存储设备的承诺。

•  **directsync**：类似于**直写，**但来自客户机的I/O绕过了主机页面缓存。在此配置中，仅当数据已提交到**cache = writeback**存储设备时，并且还希望绕过主机页面缓存时，才将写入报告为已完成。

•  **unsafe**：类似于模式，主机可能会缓存所有磁盘I/O，并且客户机的同步请求将被忽略。这是不安全的，因为如果主机发生故障，则存在巨大的数据丢失风险。但是，这在执行客户机安装或类似任务时可能会派上用场。

•  **default**：如果未指定缓存模式， 则选择系统的默认设置。

缓存选项设置可以反映在客户机XML中，如下所示：

**<disk type ='file'device ='disk'>**

**<driver name ='qemu'type ='raw'cache ='writeback'/>**

但最终配置是I/O模式。

**I/O****模式**

I/O模式配置的XML表示类似于以下内容：

**<disk type ='file'device ='disk'>**

**<driver name ='qemu'type ='raw'io ='threads'/>**

I/O模式有三个主要选项：

•  **IO = native**：此模式引用具有直接I/O选项的异步内核I/O（AIO）。预计这将在块设备上表现更好；但是，当我们使用此选项时，需要设置**cache = none/directsync**。如果未设置此缓存选项，libvirt将回退到**io = threads**模式。

•  **IO = threads**：默认是基于主机用户模式的线程，可以通过**io = threads**选项设置。期望这种异步IO模式在文件系统上表现更好。

•  **IO =** **default**：将考虑默认值。简而言之，您应该考虑将**io = native**用于基于块设备的VM。

**I/O****调整**

特别是当您的设置中存在多个虚拟机时，可能需要限制每个虚拟机的磁盘I/O。这是因为，如果只有一个客户机使主机系统忙于从中生成的磁盘I/O数量，那是不公平的！一般而言，确保所有运行中的客户机获得足够的资源进行工作是系统管理员/虚拟机管理员的责任，换句话说，**就是服务质量**（**QOS**）！这是可以保证的。即使磁盘I/O不是必须考虑的唯一资源来保证这一点，但这仍然具有一定的重要性。此调整可以防止客户机系统过度利用共享资源，并防止影响同一虚拟机管理程序中共存的其他客户机系统的性能。这确实是一个要求，尤其是当主机系统正在为VPS或类似类型的服务提供服务时。KVM提供了灵活性，可以独立于客户机上的每个块设备进行I/O节流，并支持吞吐量和I/O操作的限制。

这可以通过**virsh blkdeviotune**命令来实现。接下来显示使用此命令可以设置的不同选项：

virsh blkdeviotune命令

从前面的命令输出中可以很好地理解有关参数的详细信息，例如**total-bytes-sec**，**read-bytes-sec**，**writebytes-sec**，**total-iops-sec**等，并且还记录在**virsh**命令手册页中。

例如，要在名为**centos-1**的**虚拟机**上限制磁盘**vdb**到每秒2000 I/O操作和每秒50 MB的吞吐量，请运行以下命令：

**\# virsh blkdeviotune centos-1 vdb --total-iops-sec 2000 --total-bytes-sec**

**52428800**

**KVM****中的网络调整**

我在大多数KVM环境中看到的是，来自客户机的所有网络流量都将采用一条网络路径。不会有任何流量隔离，这会在大多数KVM设置中引起拥塞。作为网络调整的第一步，我建议您尝试使用其他网络或专用网络进行管理，备份或实时迁移。但是，当您的流量具有多个网络接口时，请尽量避免同一网络或网段使用多个网络接口。如果这一切都在起作用，请应用一些此类设置常用的网络调整。例如，使用**arp\_filter**防止ARP Flux（一种在主机和客户机中都可能发生的不良状况，是由计算机响应来自多个网络接口的ARP请求引起的）：

**echo 1>/proc/sys/net/ipv4/conf/all/arp\_filter****或编辑****/etc/sysctl.conf****以使此设置持久化。**

有关ARP通量的更多信息请参阅**[http://Linux-ip.net/html/ ][http_Linux-ip.net_html_][ether-arp.html\#ether-arp-flux][http_Linux-ip.net_html_]**。

下一个调整可以在驱动程序级别进行；也就是说，到目前为止，我们知道与仿真设备API相比，virtio驱动程序可提供更好的性能。因此，显然应考虑在客户机系统中使用**virtio\_net**驱动程序。当我们使用**virtio\_net**驱动程序时，它在**qemu** 中有一个后端驱动程序，负责从客户机网络发起的通信。即使性能更好，该区域中的其他一些增强功能还是引入了名为**vhost\_net**的新驱动程序。**vhost\_net**是一种字符设备，可用于减少virtio网络中涉及的系统调用次数。换句话说，vhost为KVM提供了内核内virtio设备（**[https://lwn.net/Articles/346267/][https_lwn.net_Articles_346267]**[）][https_lwn.net_Articles_346267]。尽管**vhost**是可以由不同的驱动程序使用的通用框架，但网络驱动程序**vhost\_net**是最早的驱动程序之一。以下屏幕截图将使这一点更加清晰：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtio</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtual</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Machine</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Kernel</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Network</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Network</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>vhost_net</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Bridge</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtual</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Machine</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>vhost</p> </td> 
  </tr> 
 </tbody> 
</table>

资料来源：**access.redhat.com**

您可能已经注意到，新的通信路径确实减少了上下文切换的数量。好消息是，客户机系统不需要任何额外配置即可支持**vhost****，**因为前端驱动程序没有变化。

**vhost\_net**减少了复制操作，降低了延迟和CPU使用率，从而产生了更好的性能。首先，必须将名为**vhost\_net**的内核模块（请参阅下一节的屏幕快照）加载到系统中。由于这是主机系统内部的字符设备，因此会在主机上创建一个名为**/dev/vhost-net**的设备文件 。该字符设备用作配置 **vhost-net**实例的接口。

**如何打开它？**

使用**-netdev tap****，****vhost = on**启动QEMU **时**，它将打开**/dev/vhost-net**并使用多个**ioctl****（）**调用初始化**vhost-net**实例。此初始化过程将**qemu**与**vhost-net**实例以及其他操作（例如功能协商等）绑定在一起：

<table> 
 <tbody> 
  <tr> 
   <td> <p>vhost kernel module information</p> </td> 
  </tr> 
 </tbody> 
</table>

接下来显示我的KVM主机的片段：

**--snip-- of qemu-kvm process ...**

**-netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci, netdev=hostnet0,id=net0,mac=52:54:00:49:3b:95,bus=pci.0,addr=0x3 --/snip--**

**vhost\_net**模块可用的参数之一是**experimental\_zcopytx**。它有什么作用？此参数控制称为“ **桥接零复制传输****”****的**东西。让我们看看这意味着什么：

**--snip--****来自****http://www.google.com/patents/US20110126195**

*“**用于在虚拟化环境中提供零副本传输的系统包括管理程序，该管理程序接收与客户机应用程序相关联的数据包有关的客户机操作系统（**OS**）请求，其中该数据包位于客户机**OS**或虚拟机管理程序还向客户机网络应用程序发送请求，以通过网络设备在网络上传输数据分组，该请求程序标识了客户机应用程序的缓冲区，并且至少具有在网络堆栈处理期间创建的部分头部。数据包驻留在客户机**OS**的缓冲区或客户机应用程序的缓冲区中，并且虚拟机监控程序会阻止将数据包复制到虚拟机监控程序缓冲区中。**”*

如果您的环境使用大数据包，则此参数配置可能会产生明显的效果。当客户机与外部网络通信时，通过配置此参数可以减少主机CPU开销。在以下情况下，这不会影响性能：

• 客户机之间的沟通

• 客人主持

• 小数据包工作量

此外，可以通过启用多队列virtionet（**[https://fedoraproject.org/wiki/Features/MQ\_virtio\_net][https_fedoraproject.org_wiki_Features_MQ_virtio_net]**）获得性能改进。

使用**virtio-net**的瓶颈之一是其单一的RX和TX队列。即使有更多的vCPU，网络吞吐量也受到此限制的影响。由于**virtio-net**只有一个TX和RX队列，因此客户机无法并行传输或检索数据包。为了解决这个限制，开发了多队列虚拟网络。直到这种实现发生为止，虚拟NIC仍无法利用Linux内核中可用的多队列支持。**tap/virtio-net****后端**必须序列化并发传输/接收请求，该请求来自不同的CPU，这导致了性能开销。

通过在前端和后端驱动程序中引入多队列支持来消除此瓶颈。这也有助于客户机使用更多vCPU进行扩展。

要使用两个队列开始的客人，您可以指定**队列**参数加到**自来水**和**为****Virtio****网**，具体如下：

**\#qemu-kvm -netdev tap****，****queues = 2****，****...-****设备****virtio-net-pci****，****queues = 2****，****...**

等效的客户机XML如下：

**<interface type='network'>**

**<source network='default'/>**

**<model type='virtio'/>**

**<driver name='vhost' queues='M'/>**

**</interface>**

其中**“ M”**可以是1到8，因为内核为多队列分接设备最多支持八个队列。一旦在guest **虚拟机中**为**qemu**配置了它，我们需要通过**ethtool**命令启用多队列支持。通过**ethtool**启用多队列（K的值从**1**到**M**），方法是：

**\#ethtool -L eth0****组合为****'K'**

在以下情况下，多队列virtio-net可提供最大的性能优势：

• 流量数据包相对较大。

• 虚拟机同时在许多连接上处于活动状态，虚拟机之间，虚拟机到主机或虚拟机到外部系统之间都运行流量。

• 队列数等于vCPU数。这是因为多队列支持优化了RX中断亲和力和TX队列选择，以使特定队列对特定vCPU私有。

尽管如此，请测试对设置的影响，因为在这种情况下，即使网络吞吐量令人印象深刻，CPU消耗也会更大。

其他网络调整选项包括**设备分配**和**单根****IO****虚拟化**（**SR-IOV**）。设备分配只是将主机物理NIC直接分配给客户机系统。显然，这可以提高性能，但是请注意，该设备不适用于主机和其他客户机系统。有关如何在KVM平台中进行设备分配和SR-IOV的更多信息，请参考前面的章节：

<table> 
 <tbody> 
  <tr> 
   <td> <p>Hypervisor</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>I/OMMU(IntelVT-dorAMDIOMMU)</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>HostSystem</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>SR-IOVPCIDevice(NIC)</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>GuestOS</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtual</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtual</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Guest1</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Guest2</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>PhysicalNIC</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Driver</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Physical</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Function</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtual</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Function</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Virtual</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td> <p>Function</p> </td> 
  </tr> 
 </tbody> 
</table>

SR-IOV图片其他参考：

**[https://fedoraproject.org/wiki/Features/KVM\_PCI\_Device\_Assignment ][https_fedoraproject.org_wiki_Features_KVM_PCI_Device_Assignment][https://fedoraproject.org/wiki/Features/SR-IOV][https_fedoraproject.org_wiki_Features_SR-IOV]**

**KVM****客户机计时最佳做法**

有不同的计时机制。**网络时间协议（****NTP**）是最著名的技术之一，它是一种网络协议，用于通过分组交换的可变延迟数据网络在计算机系统之间进行时钟同步。在虚拟化环境中需要考虑的一件事是，客户机时间应与虚拟机管理程序/主机同步，因为这会影响许多客户机操作，并且如果不同步，则可能导致无法预测的结果。

但是，有多种方法可以实现时间同步。这取决于您的设置。我见过人们使用NTP，使用**hwclock –s**从硬件时钟设置系统时钟，依此类推。这里需要考虑的第一件事是尝试使KVM主机时间同步且稳定。您可以使用类似NTP的协议来实现。到位后，客户机时间必须保持同步。尽管执行此操作的机制不同，最好的选择还是使用**kvm-clock**！

**kvm****时钟**

**kvm-clock**也称为可感知虚拟化（半虚拟化）的时钟设备。使用**kvm-clock****时**，客户机会向系统管理程序询问当前时间，以确保稳定和准确的计时。该功能通过客户机注册页面并与管理程序共享地址来实现。这是客户机和管理程序之间的共享页面。系统管理程序会不断更新此页面，除非要求其停止。客户机只要 需要时间信息，就可以简单地阅读此页面。但是，请注意，虚拟机管理程序应 支持**kvm-clock****，**以供客户机使用。有关更多详细信息，您可以参考**[https://lkml.org/lkml/2010/4/15/355][https_lkml.org_lkml_2010_4_15_355]**[。][https_lkml.org_lkml_2010_4_15_355]

您可以通过以下方法验证**kvm\_clock**是否已加载到客户机中 ：

**\[root@kvmguest \]$ dmesg |grep kvm-clock**

**\[ 0.000000\] kvm-clock: Using msrs 4b564d01 and 4b564d00**

**\[ 0.000000\] kvm-clock: CPU 0, msr 4:27fcf001, primary CPU clock**

**\[ 0.027170\] kvm-clock: CPU 1, msr 4:27fcf041, secondary CPU clock …..**

**\[ 0.376023\] kvm-clock: CPU 30, msr 4:27fcf781, secondary CPU clock**

**\[ 0.388027\] kvm-clock: CPU 31, msr 4:27fcf7c1, secondary CPU clock**

**\[ 0.597084\] Switched to clocksource kvm-clock**

进一步验证，当前客户机将其用作时钟源可以通过以下方式完成：

**\# cat /sys/devices/system/clocksource/clocksource0/current\_clocksource**

**kvm-clock**

因此，请使用**kvm\_clock**（建议做法）以获得最佳结果！

**摘要**

在本章中，我们介绍了KVM设置的性能调整方面。从virtio框架开始，我们研究了各种子系统，例如CPU和内存，磁盘和块I/O，网络时间保持以及调整的可能性。我们还介绍了NUMA概念，Hugepages，KSM以及可以应用的调整。必须对性能进行评估，并且您必须提出最佳方案来匹配您的方案。

在下一章中，我们将讨论如何使用**virt-v2v**工具将运行在外部管理程序上的虚拟机迁移到KVM管理程序。在下一章中，我们还将讨论从物理机到虚拟机的迁移。

[http]: http://www.ibm.com/developerworks/library/l-virtio/
[http_docs.oasis-open.org]: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html
[https]: https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/ch25s06.html
[http 1]: http://libvirt.org/formatdomain.html#elementsCPUAllocation
[http_libvirt.org_formatdomain.html_elementsCPUTuning]: http://libvirt.org/formatdomain.html#elementsCPUTuning
[http_libvirt.org_formatdomain_]: http://libvirt.org/formatdomain.html#elementsMemoryTuning
[http_www.Linux-kvm.org_page_KSM]: http://www.Linux-kvm.org/page/KSM
[https_www.kernel.org_doc_Documentation_vm_ksm.txt]: https://www.kernel.org/doc/Documentation/vm/ksm.txt
[http 2]: http://libvirt.org/formatdomain.html#elementsNUMATuning
[http_events]: http://events.Linuxfoundation.org/sites/events/files/slides/summit2014_riel_chegu_w_0340_automatic_numa_balancing_0.pdf%5D
[http_www.Linux-kvm.org_page_Qcow2]: http://www.Linux-kvm.org/page/Qcow2
[https_people.gnome.org_markmc_qcow]: https://people.gnome.org/~markmc/qcow-image-format.html
[https_en.wikipedia.org_wiki_Qcow]: https://en.wikipedia.org/wiki/Qcow
[http_Linux-ip.net_html_]: http://Linux-ip.net/html/ether-arp.html#ether-arp-flux
[https_lwn.net_Articles_346267]: https://lwn.net/Articles/346267/
[https_fedoraproject.org_wiki_Features_MQ_virtio_net]: https://fedoraproject.org/wiki/Features/MQ_virtio_net
[https_fedoraproject.org_wiki_Features_KVM_PCI_Device_Assignment]: https://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment
[https_fedoraproject.org_wiki_Features_SR-IOV]: https://fedoraproject.org/wiki/Features/SR-IOV
[https_lkml.org_lkml_2010_4_15_355]: https://lkml.org/lkml/2010/4/15/355