这是做应用运维老生常谈的一个事儿，经常做，今天把他总结一下。
不管什么性质的业务，吞吐量的本质是木桶原理，能跑多大量取决于木桶最短的那个板，脑袋里是不是立刻可以出现木桶的那个模型，哈哈！！换句话说，当有能力提高短板的高度时，业务的吞吐量就会有所上升，但同样有个边际效应，经过多次的优化后，当再次提高短板的成本非常非常大，而付出后提高的量很低时，那就不要较劲了，直接加服务器吧。
言归正传，先解释一下单机QPS跑不上去的现象，具体表现就是高过一个点后错误率增加、时延增大，很显然遇到短板了，那么这个短板在哪呢，开发过来二话不说要求加服务器，难道作为应用运维就直接向老板要么？服务器或许已经够多了，用户总量你心中知道没有多少，用户增量也没多加多少，用户体验没增加多少，但业务上服务器成本却像一个无底洞一样，需要不停的增加扩容，那么这个时候就该静下心分析一下了，到底是什么原因导致业务跑不上去？负责任的说，运维这个职务给公司省钱就是给公司挣钱了，这个数字还特别可观。
一、系统本身
分析的整体方法是由浅入深、层层深入，先看服务器本身的指标有没有遇到短板，这个层面的分析也是相对最容易的，在配置层面（ulimit相关例如fd等）检查没有问题后，从下面四个方面进行分析。
1、cpu
cpu粗面上看有两个指标，当前使用率和负载，使用率反应的是当前cpu使用的情况，而负载反应的是cpu任务的队列情况，也就是说任务排队情况。一般cpu使用率在70%一下，负载在0.7*核心数以下，cpu的指标就算正常。
也有例外情况，得详细分析cpu细致使用指标，恰巧被我遇到过，阿里云的ecs，整体cpu利用率不高，但业务不上量，和晓峰查后cpu0的软中断极高，单核经常到100%，继续查后发现网络中断都在cpu0上，无法自动负载，网卡不支持多队列，cpu0的单核瓶颈造成了业务整体瓶颈。
cpu用满的解决办法很简单，查程序没有bug、无大的优化空间后，那就是加机器或者换cpu类型的机器，cpu我好像没有单加过。
2、内存
内存常规看的是使用率。这个在做cdn的小文件缓存时遇到过，当时用的是ats，发现程序经常重启，业务跟着抖动，后查日志发现OOM，当内存快要被占满的时候，kernel直接把ats的进程给杀掉了，然后out of socket memory，当时留的截图如下
同样，在应用程序层面没有大的优化空间，那就加内存吧！！
3、IO
IO主要指的是硬盘IO，我一般用iostat -kdx 1看后面的比率，当一只超过50%，且偶发到100%，这说明磁盘肯定是到瓶颈了。
这个在新浪做图片业务时遇到过，是一个源站的裁图业务，在设计上为了避免重复裁图，在本地硬盘上还存了一份近7天的图，由于用python写的，没有像JVM那种管理内存的机制，所有的IO都在硬盘上。有一天业务突然挂了，和开发查了2个多小时未果，中间调整了各种参数，紧急扩容了两台机器依然不起作用，服务的IO高我们是知道的，查看IO粗数据和历史差不多，就没往那方面深考虑，艳波后来请来另外一个业务的开发徐焱同学，经验颇多，查后当机立断使用挂载内存的方式替换掉硬盘的IO操作，IO立马下来了，服务恢复。
IO问题也得综合的解决，一般从程序逻辑到服务器都要改造，程序上把重IO的逻辑放在内存，服务器上加SSD吧。
4、网络
网络主要是看出、入口流量，要做好监控，当有一天网络千兆网卡流量曲线跑平了，那么业务就出问题了。
之前在运维图片业务时遇到过网卡跑满的情况，是一个图片（小文件）的源站存储业务，突然就开始告警，各种5XX，查后5XX并无规律，后看网卡发现出流量跑满了，虽然网卡是千兆不是万兆，但按道理就cdn的几个边缘节点过来回个源，不至于跑满，将文件拿出来分析后发现问题，开发的同学为了使用方便，将新闻app的apk升级包的大文件放到这个业务上了，很坑！！
网卡的解决方式很多，做bond和换万兆（交换机要支持），当前的情况我们后来改了业务逻辑，大于多少M上传时自动去大文件服务了。
二、程序代码
当查了cpu、内存、IO、网络都没什么问题时，就可以和开发好好掰扯掰扯了，为什么服务器本身没什么压力，量却跑不上去，不要以为开发写的程序都很优良，人无完人何况是人写出来的程序呢？很多时候就是程序或技术架构本身的问题跑不上去量，这个过程我们还是要协助开发分析技术架构的，是不是程序cpu和内存使用的不合理，是不是可以跑一下多实例，把某些逻辑比较重的点做下埋点日志，把执行的全过程apm数据跑出来进行分析，等等。
三、服务架构、业务逻辑
发展至今，微服务架构设计已成为大型互联网应用的标配，各模块间通过HTTP、RPC等相互依赖、相互调用，如果查完服务器、程序依然没有问题，再往深处走就得协同开发分析逻辑、架构了，这也是微服务架构下的一个特色，不是因为服务器的某个短板造成了业务瓶颈，而是某个模块的短板造成了整个业务吞吐量上不去，这个很好理解，甚至有很多接口用的是公网公共服务的接口。
在操作上，从一次完整请求的角度，从头到尾理一遍外部依赖的上下游资源和调用关系，外部资源包括api接口、DB等，然后在每个点做埋点日志，将数据进行分析，我们在线上用这种方法不知道分析出了多少瓶颈，如果程序没有做很好的降级熔断，由于程序本身的执行是堵塞的，一个接口慢影响到整个请求，进而QPS上来后请求变慢错误数增高的例子很多，在这种情况下，如果瓶颈的接口是别的部门或公网资源，加多少服务器都解决不了问题，进行结构改造吧。
好了，写到这，希望对遇到问题不知如何下手的你有所帮助！！
查看更多请到博主原创站：运维网咖社（www.net-add.com）
原文地址：http://blog.51cto.com/benpaozhe/2121710