【APMCon 2016】LinkedIn Staff Software Engineer 庄振运:采用容器部署应用的性能考虑

如需转载请联系听云College团队成员小尹 邮箱:yinhy#tingyun.com

中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会,首次举办的APMCon以“驱动应用架构优化与创新”为主题,致力于推动APM在国内的成长与发展。

LinkedIn Staff Software Engineer 庄振运于基于云架构的性能优化专场发表了题为《容器里面乾坤大:采用容器部署应用的性能考虑》的演讲,现场解读了LinkedIn使用容器部署中的一些经验,重点介绍容器部署中几种影响性能的场景,比如内存压力场景,JVM在容器内运行的场景,不同容器互相干扰的场景等。

1.jpg

以下为演讲实录:

庄振运:大家好,我叫庄振运,今天很高兴能在这里跟大家分享关于容器部署性能方面的知识。今天我首先会介绍一下问题的背景,然后讲几个用容器部署时的性能陷阱,后面就是怎么解决这些陷阱,最后会有一点总结。

2.jpg

首先简单自我介绍下,我现在在美国的LinkedIn工作,如果大家关注新闻就应该知道,应该说我是从Microsoft来的,因为Microsoft已经和LinkedIn合并了。我的专长是Performance engineering方面,十几年来一直都做这个方面。Performance工程师跟开发这个领域不太一样,基本上要求各方面的知识都要了解多一些,因为真正的性能出问题的时候,可能在任何一个层面,我这里列了几点,大家有兴趣可以多了解这些东西,可以帮助大家debug。括号里面是我自己亲自做过的一些东西,上面是应用层,往下如果用Java的话有Java的JVM,现在容器用的也很多,这是在OS之上的,OS本身还有很多机制,像内存管理、CPU调度等都是跟性能息息相关的,再下面就是网络、硬件,像Storage等等。个人的专业之外还喜欢中国的文化,听起来很奇怪,在美国搞IT却喜欢中国的文化。

3.jpg

言归正传,今天要讲的问题背景就是Docker或者cgroups,大家知道Docker现在很流行,但是Docker的基础是什么?是cgroups。cgroups是用来分离资源使用的,比如如果有一个应用程序,我想限制CPU的使用,目的就是我可以部署好几个应用程序在一台机器上,它们不至于互相干扰。Docker是在cgroups之上加了package,就是怎么打包,但是它的性能方面基本上是由cgroups决定的。CoreOS也是同样的道理。

在APM的背景下有三方面的相关性,因为使用Docker和cgroups,APM也要相应的做一些调整。第一,因为程序是在cgroups里面运行的,所以有很多新的、跟容器有关的metrics。第二,如果出现性能问题,也需要考虑container这块,因为有的时候性能是由它造成的,不是由JVM,甚至不是由OS导致的,就是由cgroups本身造成的,这就是为什么我今天能有机会分享一下我们在这方面做过的东西。同样如果发现有些资源的使用超过量,APM要做一些alert。

今天我只讲cgroups不讲Docker,我不会告诉你怎么使用Docker。cgroups方面我只讲Performance,具体怎么设置cgroups大家回去可以自己看。cgroups Performance本身又是一个很大的内容,根据我们的经验它现在能分离出差不多十种资源,像CPU、内存等等,每一种都是有一些性能陷阱的。今天我只讲内存方面,这已经是非常大的题目了。关于这个题目我前几天发了一个LinkedIn的blog,大家可以看一下。

4.jpg

既然大家很少有人有cgroups的背景,我现在讲一下,cgroups已经是标准的linux内核机制了。大家百度或者Google一下怎么用,很容易设置的。这个一开始是Google开发的,后来整合到内核里面了。它有两个版本,V1和V2,现在大家用的都是V1,V2刚刚开始发布。一个Linux系统一开始就算你没有设置任何的东西,也有一个root cgroup。root cgroup就是你机器上运行的所有的进程,而且默认都在cgroup里面。但是你可以设置一个regular cgroup,这种普通的cgroup你可以告诉它说你最多只能用10G的内存,最多只能用2核的CPU等等,然后你把想要限制的进程或者应用程序放到这个cgroup里面,告诉它的进程ID就可以。这样以后所有在cgroup里面的应用程序,一起共享你给它定的限制,比如说10G,就是这个道理。你可以设置多个cgroup,每个cgroup可以有资源的限制。通过这样的限制,cgroup不至于互相干扰,不至于影响别人,你得到你要的份额,但是也不要能超过这个份额。

现在稍微讲一下cgroup的内存使用,如果说10G,实际上是分三块,一个是用户空间的内存使用,有的时候也叫匿名空间。另外一块是内核空间的page cache,如果你读一个文件或者写一个文件,数据都跑到page cache里面,这两块加上一块没有申请的备份,三块加在一起才是你的limit,一共是10G,这是基本的原理。Linux系统都有一个swappiness,swappiness所有的cgroup一起来共享它,你可以配置swappiness的值,这个值大家可能不太熟悉,操作系统回收内存的时候基本有两个途径,第一个就是丢page cache,第二个就是swap。怎么控制用哪块回收呢?就是用swappiness参数设置,0到100之间,100就是告诉操作系统去swap不要丢page cache,0正好是相反的,这些都是基础的知识。

5.jpg

下面讲一下cgroups使用时遇到的性能相关的陷阱。在讲之前我会提供一些跟每个陷阱相关的数据。我的setup是这样的,硬件是简单的Intel Xeon E5-2680,12个物理核,64GB内存,OS是RHEL7,总共有16GB的swap,swappiness值为1,为什么这么设置我后面会讲。然后workload我是用Java application,还有其他一些cgroup的统计,比如swap,就是cgroup本身有多少内存是被swap出去的,还有rss,就是这个cgroup到底占用多少的物理内存。free是操作系统提供的一个工具,就是看还有多少的空闲内存。

首先我们来看第一个陷阱,使用cgroup的时候你给它一个内存限制,比如说10G,这个10G不是说马上就给你的,它跟虚拟机很不一样,虚拟机是10G马上就给你,别人绝对用不到的。而这个cgroup,大家熟悉一个词叫且行且珍惜,这个就是且用且给你,你用1G就给你1G,用2G就给你2G。但是有一个问题,如果一个cgroup,有10G的limit,现在用了2G,想要再申请1G,操作系统能不能给呢?操作系统如果有空闲内存当然会给,但如果没有就只能释放其他的内存满足cgroup的请求。释放内存的时候又分几种情况,一种是丢page cache,如果page cache是clean的,就是说不需要写到硬盘上,那很简单直接丢掉就可以,这个是很快的,不会对申请内存的应用程序造成任何的影响。但是如果page cache不是clean的,是dirty的,这时候需要先写在硬盘上,就是比较困难的事情了。因为硬盘写的时候很慢,应用程序需要等待,只有等待之后拿到内存才可以继续往下。进行swap操作也是一样的,如果操作系统没有空闲内存,那申请内存的cgroup就会造成性能影响。比如我们简单做一个实验,随便一个场景申请16GB的内存需要20秒,非常慢,这时候基本就停滞了,但具体是几秒取决于很多因素,比如硬盘IO怎么样等等。

接下来我们看第二个陷阱,我讲的内存的限制为10G,其实包括两部分,一个是匿名内存,一个是page cache,你每次读一部分文件或者写一部分文件都会用到一定的page cache。如果你的应用程序在机器上,你要move到cgroup里面,你首先要决定到底给它多少内存合适。这个估量有多少内存呢?其实不是那么简单的事情,匿名内存很容易估算,但是page cache是很难确定的。要点就是如果你没有给cgroup足够的page cache,会造成什么结果呢?第一,page cache就会不够,不光是你给它的时候不够,还有就是cgroup申请匿名内存的时候,因为有优先级会把原来有些page cache强制改出去,最终的结果是一样的,你的应用程序page cache不够。如果你的应用程序有很多文件操作,那么性能肯定会受影响。

6.jpg

7.jpg

这是个实验的例子,我画了两个图,第一幅图就是讲占用了多少物理内存了。我方便大家看,分三步讲解,第一步就是setup是什么样?比如有一个regular cgroup 20GB的limit,已经用了13GB的page cache,我做了什么事呢?我的cgroup再申请16GB的匿名内存,然后发生什么事情了?结果有两幅图,第一幅图是我发现cgroup的rss物理内存增加了16GB,为什么?因为我申请了16GB匿名内存,这个很正常。第二幅图就是第二个结果,page cache下降了8GB,这个差是因为有其他地方的page cache也下降了,所以才能弥补这16GB。

第三个性能陷阱,操作系统可以回收所有cgroup的page cache。我刚才讲的page cache属于每个cgroup的内存限制里面,举个例子来讲。假设你是cgroup,你有10G的limit,你现在只用了2G的匿名内存,2G的page cache,你还有6G的份额,你会觉得我才用了一点,不应该把我的page cache丢掉,但实际不是这样的。操作系统维护所有的page cache,如果别人需要新的page cache,操作系统决定丢page cache的时候会任选一个,根本不考虑你到底用了多少,也不考虑这个page cache属于谁,完全是盲目的。也就是说你作为一个cgroup,你才用了4G,你还有6G的空间,那很不幸你的2G的page cache也可能被干掉,这就会造成性能的影响,你的性能是不能预测的,因为别人会把你的东西偷走。

8.jpg

9.jpg

我做了一个实验,我有一个cgroup 20GB limit,用了差不多4.8GB的page cache,另外的cgroup也开使用page cache,向操作系统申请。操作系统就决定把前一个cgroup的page cache丢掉2.6GB,同时root cgroup也降低了5.5GB。这就告诉我们操作系统其实内部只有一个,大家如果对container稍微熟悉一点的话,page Cache有一个list,丢的时候是从list里丢最老的,这个最老的当然属于任何一个cgroup,它看到之后就丢掉,不管你是属于谁的。

第四个陷阱有点类似,我刚才讲过了page cache,另外一块就是匿名内存。道理也差不多,它不会被丢掉,但是会被swap出去到硬盘上。这个swap过程也是由操作系统完全维护的,它想swap哪个匿名内存,也是不考虑它的所有者,不考虑它属于哪个cgroup,完全是根据内部的算法。

10.jpg

大家看这个实验稍微复杂一点的,有两个regular cgroup都用了匿名内存。其中一个regular cgroup开始用新的内存,操作系统没有新的内存了,怎么办?它会swap掉一些匿名内存,这个swap分三块,一块是root cgroup,另外两块是regular cgroup,都会被swap出去。我们可以看到,第一个cgroup的swap size在不断的增加,因为它被放到硬盘上去了。对于第一个cgroup的rss,因为它的内存被swap出去了,有一块被放到硬盘去了。第二个cgroup和第一块很像,也是swap越来越多,占用物理内存,它在申请匿名内存,在增加。第三个是root cgroup的swap size也在增加。我再重复一下,重要的事情多重复几遍。如果操作系统决定swap匿名内存,它不会顾及你到底是哪个cgroup,它想swap就swap,没有人限制它。

11.jpg

第五个陷阱稍微有点不太一样,是关于虚拟内存地址空间的,大家可能对这个不是特别熟。这里有两个概念是有区别的,一个是Resident set size,就是它真正作用了多少物理内存,第二个是Virtual Memory,占用多少虚拟地址空间,这个肯定比物理上稍微大点。top我相信大家都用过,非常普通的命令。下面的数据就是整个系统的统计数据,重要的我用红圈画了。现在几个进程,比如说第一个进程是Java用了12G的物理内存,差不多25G的虚拟内存。这个大家可以看到,它远远超过了12G的虚拟地址空间,这个大家怎么想?可能觉得虚拟地址无所谓,其实这个会导致你的应用程序启动不起来,甚至突然死掉,为什么?因为系统里面有很多的设置,比如overcommit,如果没有打开,整个系统的虚拟内存地址空间是有限的,有一个办法取决于你的swap size,还有你的物理内存size。这个配置有64GB的虚拟地址空间,这64BG不是一个进程的,也不是一个cgroup的,是整个系统的。有一个问题,作为一个应用程序它用多了,用了63G,那别人只有1G,那别人如果想再启动一个Java,就可能启动不起来,或者突然想多要一点内存也会死掉,因为没有了。

12.jpg

大家说为什么拿Java说事?因为Java在这方面是比较讨厌的。首先我还是解释一下这几个概念,第一个是Java的JVM heap,有一个小的值,也有一个大的值。小的值就是初始值,大的值就是最多不会超过的值,像这个就是5G。第二个就是RSS,RSS就是占用多少物理内存,包括堆和堆外的一些东西,像perm、meta、direct都属于堆外的内存。第三个就是虚拟内存,我有点简化了,基本上你的RSS加上glibc memory pool。

13.jpg

这个表格看起来挺复杂的,我简单讲几列,我的setup的heap是5G,12核的一个机器,glibc大家都知道,如果12核乘8就是100个thread,一个thread是64M,总共就是6个G的虚拟空间,这是最大值。像这个表左边第一个列,就是应用有几个thread,我发现这个JVM有24个thread,有23个是JVM本身的thread。看最右边的一列,总共用了8.3G的虚拟地址空间,这是真正的值,其他是根据简单的方程算出来的。大家看最后两列很像,我们的理解基本是对的。要点就是大家看最后这两行值,对于50个thread或者100个thread,基本上用了差不多12G、13G的虚拟地址空间。为什么这个值有用?还是回到整个系统的限制,整个系统的虚拟地址空间有限,假设你是64GB的总的地址空间,如果一个就需要12G,那么顶多就是5个cgroup,而且还没考虑别人,比如操作系统。也就是说你这个服务器不管多强大,只能5个cgroup,超过5个就不行。

我们刚才讲了五个性能的陷阱,那怎么解决呢?

1、第一个方案,把应用程序搬到cgroup里面的时候,要特别小心我们需要给多大的内存限制,这里面仔细想想还挺复杂的。一个是匿名内存,一个是page cache。匿名内存就比较简单,第一个它很准确,你用多少就是多少,一般来说会不断增加,这个最大值就是它需要的。第二个就是Linux有很多tool可以帮你看,比如top;但是page cache比较麻烦。第一你没有tool可以帮你看。第二它不是很准确的,里面又有很多问题,我举个例子,比如log,你的应用程序其实不需要这么多的page cache,因为log写完了没人读它,丢掉就完了。同样大家应用程序启动的时候可能一开始读很多的文件,这个时候也会占page cache,同样的道理,程序运行之中其实不需要它们的。

我们提供的方法就是先把它放到cgroup里面,先放在一个测试环境里面,cgroup本身提供了很好的机制,帮你确定多少匿名内存,多少page cache。匿名内存有一个rss的统计,page cache我们是用active_file进行统计的。

2、第二个方案就是我们叫per-touching cgroups memory,既然cgroup申请内存的时候并没有拿到它的limit,那我就先拿到再说,比如说Java有一个AlwaysPreTouch,你用10G就直接10G装到内存里面,不会是且用且给你的那种状态了。再有就是把cgroup swappiness调成0,就会保护你这个cgroup的匿名内存不会被swap出去。

3、这是最重要的一点就是对root cgroup进行严格的控制,讲到内存的问题归根结底就是整个系统需要更多的内存,为什么需要更多的内存?大家可能会想到我计划好一点,就两个Java,一个10GB,整个系统64GB肯定没问题,其实不是这样的,你的系统不光有你的应用程序,还有其他的东西,比如SSD,用户远程登录之后SSD来处理请求。比如你读一个很大的文件,你的SSD就会占用很多的page cache,比如你干别的事,就会占用匿名内存,这些都会放到root cgroup里面去,所以这个完全难以控制的。要点是你对root里面的cgroup进程最好要控制一下,方法就是你把它放到单独的cgroup里面。但是仔细想想还有些小问题,你想创建一个大的cgroup,把所有的Performance放进去,还是每一个Performance放一个小的cgroup,各有利弊。

4、我们讲了很多虚拟内存的事情。虚拟内存在现在的cgroup中完全没有任何的限制,我刚才讲限制了十种资源,CPU、网络、IO等,可是没有虚拟内存的限制,我估计以后会加上。要防止每个cgroup用太多的虚拟地址,因为会影响别人,整个系统完全就不能预测了。

大家可能会觉得奇怪,cgroups为什么这么弱,它一点都不弱,这就是它的设计,设计就是这样的。因为我们认为虚拟机器是比较慢的,启动比较慢,可能几十秒启动。但是cgroups的设置理念非常快,1秒就启动了,内存不给你也正常,给的话肯定就达不到1秒了。你既然不用,那就给操作系统用,大家知道操作系统是贪得无厌的越多越好,你用的时候我再给你,这是他的设计理念。

第二个是对system processes如何进行限制?我刚才讲的一点,你把它分成小的、大的cgroup或者几个中等的分别放到容器里,根据你们系统自己的使用情况,比如说我很少用SSHD,SSHD可能就不用管它了。

第三个,大家可能会觉得你今天讲的这些情况都非常的极端,我们根本用不着,其实也不是这样的。有一个原因,一个是极端情况真的会发生,你想想现在一个大公司会有很多的机器,就算千分之一的故障率一天也是一台机器。第二就是大家商业的SLA,一般定义的时候也是99.99%,就算有一次出问题也会影响你的商业的SLA。还有就是从APM的角度来讲,既然cgroups有这么多的特征,我建议加上这个虚拟内存使用。还有就是alert,如果有cgroup影响到别人,你要实时发alert。你要再做得好一点的,你对cgroup资源的使用,包括虚拟内存的使用也进行限制就好了。最后如果发现系统问题了,你脑子里要知道有可能是由这方面导致的。

简单的回顾一下,我今天讲的cgroups Performance完全是内存相关的,我认为cgroups有很多的性能陷阱,有些情况下会导致性能的问题,分几种情况,我们需要针对每种情况采取相应的措施。谢谢大家!

APMCon2016 演讲PPT合集下载

链接: http://pan.baidu.com/s/1mhFwaZQ 密码: bezk


想阅读更多技术文章,请访问听云技术博客,访问听云官方网站感受更多应用性能优化魔力。

关于作者

APMCon2016

驱动应用架构优化与创新

我要评论

评论请先登录,或注册