关于性能问题的一些思考

问题： 网站卡顿了或者某个接口tps上不去了，怎么定位？

1. 性能问题的出现大多伴随着某个资源的瓶颈，待考量资源一般包括cpu,memory，network, disk
2. 另外， 软件一般分为io密集型和cpu密集型， 当然了，也存在部分cpu和io都密集的；io不仅仅包含disk ，也包含network
3. 所以解决问题的第一步就是发现性能瓶颈，比如幸运的是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协议

5. 最有意思的一点， 可能观察不到性能瓶颈，但是网站确实慢了，怎么办？
   这种情况往往需要具体情况具体分析了，而且其实也是出现了瓶颈，只不是相对不明显。
   这里举一个例子，我们的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去执行请求。