本站文章均为愚人乙工作实践中的心得原创,转载请注明出处,沟通交流欢迎点击加入【运维架构QQ群】991904631

微服务架构下业务单机QPS跑不上去应从哪些角度分析

互联网应用 愚人乙

不管什么业务,吞吐量的本质是木桶原理,能跑多大量取决于木桶最短那个板(脑袋里是不立刻出现了木桶模型,哈哈)!!换句话说,当有能力提高短板的高度时,业务的吞吐量就会上升,但

timg (1)_meitu_3.jpg

瓶颈分析是应用运维老生常谈的一个事儿,经常做,今天总结一下,希望对你有所帮助。

不管什么业务,吞吐量的本质是木桶原理,能跑多大量取决于木桶最短那个板(脑袋里是不立刻出现了木桶模型,哈哈)!!换句话说,当有能力提高短板的高度时,业务的吞吐量就会上升,但同样有个边际效应,经过多次的优化后,当再次提高短板的成本非常非常大,而提高的量却很低时,那就不要较劲了,直接加服务器吧

005DaU4fzy7975keBZY06&690.jpg

言归正传,先讲一下QPS跑不上去的现象,表现就是高过一个点后错误率增加、响应时间变长、用户体验变差,带来的副作用就是用户的流失,很显然是遇到瓶颈了,那么瓶颈在哪儿,我们怎么分析呢?

开发二话不说要求加服务器,作为应用运维不过脑子直接向老板要么?服务器或许已经够多了,用户总量你心中知道没有多少,用户增量也没多少,但业务上对服务器的需求却像无底洞一样,需要不停的扩容再扩容,其实这个时候就该静下心来分析一下了,到底是什么原因导致吞吐量跑不上去?负责任的说,运维给公司省钱就是给公司挣钱了,抓到点上这个数字还特别的可观,总结后,一般瓶颈问题从下面三个维度来分析。

一、机器本身

分析的整体方法是由浅入深、层层深入,先看服务器本身的指标有没有遇到短板,这个层面的分析也是相对最容易的,在配置层面(ulimit相关例如fd等)检查没有问题后,从下面四个方面进行分析。

1、cpu

cpu粗面上看有两个指标,当前使用率负载,使用率反应的是当前cpu使用的情况,而负载反应的是cpu任务的队列情况,也就是说任务排队情况。一般cpu使用率在70%以下,负载在0.7*核心数以下,cpu的指标就算正常。

也有例外情况得分析cpu的详细指标,在运维小米消息系统的一个模块时,服务器用的是阿里云的ecs,整体cpu利用率不到30%,但业务就是跑不上量,和肖坤同学查后发现cpu0的软中断极高,单核经常打到100%,继续查后发现网络中断都在cpu0上无法自动负载,和阿里云工程师确认后是所在机型不支持网卡多队列造成的,最终定位cpu的单核瓶颈造成了业务整体瓶颈,如下图:

image.png

cpu用满的解决办法简单粗暴,在程序无bug的前提下,换机型加机器,cpu本身没单独加过。

附一篇排查cpu问题的博文:4核服务器cpu使用率10%负载飙到23.5故障排查

2、内存

内存常规看的是使用率。这个在做cdn的小文件缓存时遇到过,当时用的是ats,发现程序经常重启,业务跟着抖动,查日志后发现系统OOM了,当内存快要被占满的时候,kernel直接把ats的进程给杀掉,然后报out of socket memory,留的截图如下:

1491836023709950.png

同样,在应用层没有优化空间时,那就加内存吧!!

3、IO

IO主要指硬盘,一般用iostat -kdx 1看各种指标,当 %util超过50%,且偶发到100%,这说明磁盘肯定是到瓶颈了。

要进一步查看是否由于IO问题造成了系统堵塞可以用vmstat 1 查看,下图b对应因IO而block的进程数量。

image.png

这个在新浪做图片业务时遇到过,是一个源站的裁图业务,设计上为了避免重复裁图,在本地硬盘上存了一份近7天的数据,由于用python写的,没有像JVM那种内存管理机制,所有的IO都在硬盘上。有一天业务突然挂了,和开发查了2个多小时未果,中间调整了各种参数,紧急扩容了两台机器依然不起作用,服务的IO高我们是知道的,查看IO数据和历史差不多,就没往那方面深考虑,后邀请经验颇多的徐焱同学参与排查,当机立断将IO处理逻辑由硬盘迁到内存上,IO立马下来了,服务恢复。

IO问题也得综合的解决,一般从程序逻辑到服务器都要改造,程序上把重IO的逻辑放在内存,服务器上加SSD吧。

4、网络

网络主要是看出、入口流量,要做好监控,当网卡流量跑平了,那么业务就出问题了。

同样在运维图片业务时遇到过网卡跑满的情况,是一个图片(小文件)的源站业务,突然就开始各种5XX告警,查后5XX并无规律,继而查网卡发现出口流量跑满了,继续分析,虽然网卡是千兆的,但按理就cdn的几个二级回源点回源,不至于跑满,将文件大小拿出来分析后,发现开发的同学为了省事儿,将带有随机数几十M的apk升级包放这里了,真是坑!!

网卡的解决方式很多,做bond和换万兆网卡(交换机要支持),当前的情况我们后来改了业务逻辑,大于多少M时强制走大文件服务。

二、程序代码

当查了cpu、内存、IO、网络都没什么问题,就可以和开发好好掰扯掰扯了,为什么服务器本身没什么压力,量却跑不上去,不要以为开发写的程序都很优良,人无完人何况是人写出来的程序呢?很多时候就是程序或技术架构本身的问题跑不上去量,这个过程运维还是要协助开发分析代码逻辑的,是不是程序cpu和内存使用的不合理,是不是可以跑一下多实例,把某些逻辑比较重的地方做下埋点日志,把执行的全过程apm数据跑出来进行分析,等等。

一个典型用运维手段解决代码瓶颈的案例详见博文:记一次HttpDns业务调优——fastcgi-cache性能提升5倍

三、逻辑架构

发展至今,微服务架构设计已成为大型互联网应用的标配,各模块间通过HTTP、RPC等相互依赖调用,如果查完服务器、程序依然没有问题,再往深处走就得协同开发分析逻辑架构了,这也是微服务系统下的一个特色,不是因为服务器或者程序bug造成了业务瓶颈,而是某个模块的短板造成了整个业务吞吐量上不去,这个很好理解,甚至有很多接口用的是公网公共服务。

具体分析上,从一次完整请求的角度,从头到尾理一遍外部依赖的上下游资源和调用关系,外部资源包括api接口、DB、队列等,然后在每个点做埋点日志,将数据进行分析,我们在线上用这种方法不知道分析出了多少瓶颈,如果程序没有做很好的降级熔断,由于程序本身的执行是堵塞的,一个接口慢影响到整个请求,进而QPS上来后请求变慢错误数增高的例子很多,在这种情况下,如果瓶颈的接口是别的部门或公网资源,加多少服务器都解决不了问题,进行改造吧,下图是运维门户业务时做的依赖接口超时监控,性能差的接口一目了然:

03后端依赖接口.png

好了,写到这,希望对遇到问题不知如何下手的你有所帮助!!

运维网咖社”原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://www.net-add.com

喜欢 (34) or 分享 (0)
欢迎点击加入【运维架构QQ群】991904631