问题： 网站卡顿了或者某个接口tps上不去了，怎么定位？
- 性能问题的出现大多伴随着某个资源的瓶颈，待考量资源一般包括cpu,memory，network, disk
- 另外， 软件一般分为io密集型和cpu密集型， 当然了，也存在部分cpu和io都密集的；io不仅仅包含disk ，也包含network
- 所以解决问题的第一步就是发现性能瓶颈，比如幸运的是linux下针对这几种资源都有比较好的工具。
3.1 全局观测-
nmon nmon可以比如方便的看到cpu,network,disk，memory是否出现瓶颈
image.png
3.2 专项检测
- cpu: top
- mem: ps
- network:iftop
- disk: iotop
其中top可以看到哪些进程占用比较高的cpu,ps可以看到各个进程占用的实际内存（ps aux）,iftop和iotop跟top比较类似，只不过监控的资源项从cpu分别换成了网络和磁盘
-
4.如何解决性能瓶颈
这里只简单的谈几个点
- cpu出现了瓶颈时，要关注下是系统cpu高还是用户cpu高
- 如果系统cpu高的话，可以用strace -c 来看下是哪些系统调用占用了cpu
- 用cpu高的话，负责的开发往往知道瓶颈可能出现在哪里， 比如存在大量循环计算， 存在大量的序列化和反序列化，可以通过优化算法来处理,找不到瓶颈时可以考虑使用profile
- disk 出现瓶颈，往往是因为大量的随机读写导致的， 这在关系型数据库中最为常见，可以考虑使用leveldb等顺序读写的kvdb解决部分性能场景
- network 出现瓶颈， 可以考虑开启http 压缩传输或者换成rpc协议
- 最有意思的一点， 可能观察不到性能瓶颈，但是网站确实慢了，怎么办？
这种情况往往需要具体情况具体分析了，而且其实也是出现了瓶颈，只不是相对不明显。
这里举一个例子，我们的nginx上配置了upstream, upstream上是100个php-cgi进程， 24核的机器，只有3个核跑满了，还有大量的核空闲，但是有的请求却始终返回很慢。
其实聪明的你一定会怀疑那3个跑满的核， 可是心里也会有疑惑，难道有那么多的空闲的cpu不用，请求非要往那3个跑满的核上扔吗？
答案确实是这样的， nginx upstream默认的请求分配策略是round robin，即轮询，按请求的顺序，依次分给upstream server。 假如有101个请求，前3个特别消耗cpu，大概需要1分钟才跑完，后面98个请求只需要1ms就能执行完，那么因为RR策略，第101个请求运气就比较差，刚好被分配到第1个请求后面，需要等1分钟之后第一个请求执行完了之后再执行，给大家造成一个假像，这个请求很耗时。
最终的解决办法很简单， 在nginx upstream的配置中， 加上least_conn选项， 让nginx选择连接数最少的那个upstream server去执行请求。
