2017版：KVM 性能优化之内存优化

标签：不能   物理内存   消失   developer   额外   一起   sha   jpg   变化   

我们说完CPU方面的优化，接着我们继续第二块内容，也就是内存方面的优化。内存方面有以下四个方向去着手：

1. EPT 技术
2. 大页和透明大页
3. KSM 技术
4. 内存限制

1. EPT技术

EPT也就是扩展页表，这是intel开创的硬件辅助内存虚拟化技术。我们知道内存的使用，是一个逻辑地址跟物理地址转换的过程。虚拟机内部有逻辑地址转成成物理地址的过程，然后再跳出来，虚拟机这块内存又跟宿主机存在逻辑到物理的转换。有了EPT技术，那么能够将虚拟机的物理地址直接翻译为宿主机的物理地址，从而把后面那个转换过程去掉了，增加了效率。

那么这项技术，现在的服务器都支持，只要在BIOS打开了intel 的VT设置，那么这个也一起打开了。

所以这个基于硬件的优化，目前不需要做额外的什么操作。

2. 大页和透明大页

我们先解释什么叫大页。

所谓的大页指的是内存的大页面。当然，有大页面必然有对应的小页面… 我们知道内存采用的是分页机制，当初这个机制提出的时候，计算机的内存大小也就几十M，所以当时内存默认的页面大小都是4KB，那么这个4KB 也就是所谓的小页面。但是随着计算机的硬件发展，现在的内存基本上都是几十G 甚至上百G了，虽然，如果还是4KB小页的方式，那么必然会存在一些问题。那么会有哪些问题呢？操作系统如果还是小页存在，那么将会产生较多的TLB Miss和缺页中断，从而大大影响性能。

为什么小页就存在较多的Miss和缺页中断呢？比如说系统里的一个应用程序需要2MB的内容，如果操作系统还是以4KB小页为单位，那么内存里就要有512个页面（512*4KB=2M），所以在TLB里就需要512个表项以及512个页表项，因此操作系统就要经历512次的TLB miss和512次的缺页中断才能将2MB的应用程序空间全部映射到物理内存里。想想，2MB内存的需要就要经历512次的操作，如果内存需求大呢？必然操作数量会大大增加，从而间接的影响性能。

如果把这个4KB变成2MB呢？那就很轻松了，一次TLB Miss和缺页中断操作就完成了，大大的增加了效率。

所以，虚拟机可以通过分配巨型页也就是刚才说的大页来提高运行性能。

那么具体怎么操作呢？也就是说如何把这个4KB的小页变成2MB甚至1GB的大页，然后把这个大页赋给虚拟机使用？

我们可以先通过命令 cat /proc/meminfo | grep HugePages查看当前系统有多少个大页：

我们看到，当前数量是0。

那么如何设置大页的数量呢？也就是上面的HugePages_Total的数量。

只要运行echo 2000 > /proc/sys/vm/nr_hugepages 这个命令即可：

已经变成了2000了。

当然这样重启会失效，我们运行这个命令让它永久生效 ：sysctl -w vm.nr_hugepages=2000

运行了这个命令系统重启的话，大页的数量也将是保持2000，不会变。

接下来，我们还得把大页进行挂载，我们运行：

这个hugetlbfs 是一种特殊文件系统，那至于为什么采用这样的文件系统是因为这样花费的代价小。

那么通过这几步操作，开启->设置大页数量->挂载， 那么宿主机这块就没什么问题了。

如果我们KVM里面的某个虚拟机要使用宿主机的大页，那么我们还得做如下操作：

1. 重启下libvirtd服务
2. 虚拟机也开启透明巨型页
3. 关闭虚拟机编辑虚拟机XML设置虚拟机可以使用宿主机的巨型页数量

我们先看看，当前的大页是没进程用的， hugepages_free是2000：

我们先把libvirtd服务重启：systemctl restart libvirtd.service

然后，我们看看虚拟机的透明大页有没有打开，一般默认系统是打开的，我们确认下

我们看到是always状态，那么就是打开的，OK，我们进行下一步。

编辑虚拟机XML文件，让它使用宿主机的大页。

我们先把虚拟机关闭，然后 virsh edit vmname 命令修改，添加下图中红色框框的内容：

修改后，保存，然后开启虚拟机，注意这个虚拟机的内存是2G的配置。

最后我们在宿主机运行cat /proc/meminfo | grep -i HugePages 查看下大页的使用情况

我们发现hugepages_free 已经变成了912个了，那么使用了2000-912=1088 个。

Hugepagesize是2M，也就是每页页面的大小，使用了1088个页面，那么2*1088=2176M  正好跟虚拟机内存的大小2G差不多。

如果想让虚拟机释放大页，那么只要把这个虚拟机关机或者删除XML里刚才添加的配置。

刚才的操作，我们只是针对一个虚拟机的，也就是说我们把大页面赋给了一个虚拟机。如果我们要赋予多个虚拟机怎么办？

那么要让大页同时让多个虚拟机享用，有以下两步要做：

1. 给NUMA 各个node节点分配多个2MB或者1GB的大页
2. 编辑虚拟机xml文件以使用node里分配好的大页

我们可以运行下面两个命令就可以给宿主机各个NUMA Node分配大页

这两个命令的意思就是先给node0里分配4个1GB的大页，然后再给node1分配1024个2MB的大页。

然后执行相关挂载操作，这跟刚才我们做的操作类似：

挂载成功后，重启下libvirtd服务，然后虚拟机就可以使用了，但是这里要注意的是，1GB的大页，虚拟机是不能直接使用的，需要在XML里指定。

那么怎么指定? 我们目前宿主机NUMA node1和node2里面分别有4个1GB的和1024个2MB的大页。因此，只要跑在这两node上的虚拟机都可以享用了。

比如刚才我们那虚拟机，我们要让它使用1GB的大页，我们只需要在XML里这样定义：

<memoryBacking>
<hugepages/>
<page size="1" unit="G" nodeset="0-3,5"/>
<page size="2" unit="M" nodeset="4"/>
</hugepages>
</memoryBacking>

红色的部分就是要添加的参数，size是1，表示第一个使用的page；然后单位unit是G，nodeset=”0-3,5″ 意思是虚拟机的NUMA node0，node1, node2 , node3和node5将使用1GB的大页 ； 虚拟机的node4将用2MB的大页。

注意，这里的nodeset指的是虚拟机的节点，同时还要注意的是，如果宿主机大页面不够用了，你这样配置了，虚拟机是会起不来的。

以上就是给虚拟机分配大页的方法。当然如果你想把宿主机的大页关闭，只要执行：

接下来我们讲下透明大页。

从Centos6开始，linux系统自带了一技术叫透明巨型页（transparent huge page），它允许所有的空余内存被用作缓存以提高性能，而且这个设置是默认开启的，我们不需要手动去操作。

Centos下，我们用cat /sys/kernel/mm/transparent_hugepage/enabled可以查看

我们看到这个中括号把这个always括起来了，说明这机器的透明巨型页的功能是打开的。当有512个页面可以整合的时候，就会合成一个2MB的大页；如果是在括号把never括起来了，那么就是关闭状态；madvise的话就是避免改变内存占用。

当然，如果你想改变透明巨型页的状态，比如说关闭它，那么运行下面的命令即可：

最后要注意的是透明巨型页跟刚才我们说的hugetlbfs 文件挂载大页是不冲突的，如果你没做任何大页的指定和挂载，那么KVM就会使用透明大页的方式。

那么说到这，大家就会疑问，既然有透明大页，我为何还要费劲的去做相关大页的指定？ 其实这两种方式都差不多，区别就是一个是手动的一，个是自动的。如果你对你宿主机资源把握的更加精准，推荐的还是手动指定。

3. KSM 技术

KSM是什么呢？KSM（Kernel SamePage Merging），也就是所谓的相同页面内存压缩技术。

KSM服务在linux系统里默认是开启的，它的作用就是让内存利用的更加高效，我们知道内存是分页的，如果多个程序中用的内存都是相同的页面，那么KSM就会把相同的内存合并，这样就能腾出更多的空间。

KSM在系统里有个守护进程，它的作用就是不断的扫描宿主机的内存情况，检测有相同的页面就会合并，这或多或少会消耗CPU。

下面有几个命令设置大家要了解：

首先是开关KSM服务：

如果你的环境，内存资源比较丰富，VM又不多，这个功能开不开启都无所谓；如果不够，又想跑多一点的虚拟机，那么可以打开这个功能。但是你一定要注意，这个是一种内存超用的方案，如果一台宿主机里大部分虚拟机内存变化比较频繁，那么要慎重开启，因为KSM会频繁的做内存扫描，不停的做内存合并操作，这会大量的消耗CPU资源，如果内存不够还会用到swap，那么最终会严重影响虚拟机性能。

当然，也有设置能让虚拟机不受宿主机KSM的影响，具体操作如下：

编辑虚拟机的XML文件，添加：

<memoryBacking>
<nosharepages/>
</memoryBacking>

这样，这个KSM就不会去合并这个虚拟机的内存了。

总的来说，如果你的环境硬件配置比较高，同时又追求VM数量，把KSM打开是一个很不错的选择（但是一定要做好相关资源的实时监控，特别是CPU）。在笔者维护过的项目中，遇到过只追求数量而不追求性能的场景，当时我们就开启了KSM服务，服务器配置是双路E5-2690 v3@2.60GHz 48core、512G内存，当每台计算节点到80个VM的时候（VM大部分配置为4c8G，windows和linux各占50%）。用htop命令监控查看CPU每个核基本上都是99%满负载，此时，虚拟机体验十分不好，后来降到60个左右，CPU负荷在60%-70%，这样情况才有明显好转。

所以，用不用KSM视你自己的生产环境和客户需求具体而定，这配置还是得慎重。

4. 内存限制技术

通过虚拟机内存限制，可以让虚拟机的内存使用限制在一定范围内。

那么这个操作有什么作用呢？比如你的一台KVM宿主机，里面跑着多个业务的虚拟机，有的虚拟机业务比较大，吃得内存多，有的业务比较低，用不了多少内存，那么我们可以通过内存限制技术来手动调节宿主机的内存分配。

当然这里要说明的是，使用这个必须对你虚拟化环境特别清楚，比如宿主机平时的负载情况以及各个虚拟机的负载情况。

那么具体如何操作呢？我们通过memtune命令或者通过改虚拟机的XML文件来设定内存的限制。

这个memtune命令有以下4个参数

hard_limit：强制设置虚拟机最大使用内存，单位为KB

soft_limit：可用最大内存，单位为KB

swap_hard_limit：虚拟机最多使用的内存加上swap的大小，单位为KB

min_guarantee：强制设置虚拟机最低使用的内存，单位为KB

最后一个参数虽然OPTIONS里有列出，但是实测是发现CentOS7.0 以上系统不能支持，执行的时候会报下面这样的错误：

centos6 虽然不会报这个错，但是这命令貌似也不会有实际效果

官方解释这是一个bug，大家可以参考下面的链接：

https://bugzilla.redhat.com/show_bug.cgi?id=1122455

–config ： 写入配置文件中，虚拟机重启后生效

–live ：让设置立即生效，但是虚拟机重启后，效果消失 （如果不加–config –live –current 那么默认是这个）

–current ：影响关机或者运行状态的虚拟机，如果当前虚拟机正在运行，那么虚拟机停止后，效果会消失

例：

这个设置可以慎用，因为虚拟机使用了swap那么速度性能肯定会下降很多，而且要注意的是，这里设置的内存大小必须大于hard-limit

这个命令我们可以操作下，但是演示会发现前面所说的error

以上是通过命令的方式，我们刚才说了，还可以通过修改XML的方式来现在虚拟机的内存。

我们在XML里添加下面这个配置即可：

<memtune>
<hard_limit unit=’KiB’>9437184</hard_limit>
<soft_limit unit=’KiB’>8388608</soft_limit>
<swap_hard_limit unit=’KiB’>10485760</swap_hard_limit>
</memtune>

注意第四个参数min_guarantee加里面会报错，虚拟机启动不了。

以上几点就是KVM在内存方面的相关调试设置。作为工程师首先要做的是熟悉底层各种参数，然后根据生产环境和客户需求做出最优配置，这样才能得出最强的性能。

性能调优，这个很吃经验，所以第一步还是熟悉下平台里原生有哪些设置参数以及它们的作用吧！

参考链接：

http://blog.csdn.net/summer_liuwei/article/details/6013255

https://www.ibm.com/developerworks/cn/linux/l-cn-hugetlb/

http://lduan.blog.51cto.com/5428084/1716188

http://www.oracle.com/technetwork/cn/articles/servers-storage-dev/hugepages-2099009-zhs.html

https://access.redhat.com/documentation/zh-CN/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/chap-Virtualization_Tuning_Optimization_Guide-Introduction.html#sect-Virtualization_Tuning_Optimization_Guide-Introduction-KVM_Overview

原文：云技术实践

http://syswift.com/100.html

2017版：KVM 性能优化之内存优化

标签：不能   物理内存   消失   developer   额外   一起   sha   jpg   变化   

原文地址：http://www.cnblogs.com/allcloud/p/7776713.html