关于服务器碰到性能瓶颈的思考

这是我的一些想法：

       当cpu出现瓶颈的时候，首先考虑从软件方面还有没有改进的余地，比如说代码算法的设计，像我写的这个avl树其实还有更好的插入和删除算法，可以用栈和循环来解决循环嵌套问题，从而减少函数栈出栈入栈的消耗；比如说计算无人机传回的两个gps location之间的直角坐标系向量，可以通过近似Δx = (x1.longitude-x2.longitude)*pi/180*α来计算从而减少计算量，这个思想在sql中需要计算比较复杂的值但精度要求不是太高时可以应用。

       还有就是考虑代码有没有充分的利用cpu，可以通过top查看各个核的使用情况，也可以用vmstat看进程等待和阻塞的情况来进行分析，像上面进行的并行测试，看似多个线程对应多核很完美，其实因为一次只能有一个线程在具体操作avl树导致其他线程都在等待，造成了很大的浪费，不过这也是因为avl树的特性（插入等操作会影响整棵树），如果是普通搜索二叉树的话可以细化锁的粒度，仅锁住插入的那个节点，就可以很大的提升cpu利用率了。不过其实更好的办法是通过一些技巧避免锁，比如MVCC技术在innodb里通过事务id控制版本，像update操作会产生一个新版本数据和一个旧版本数据，根据事务id来决定读取新版本还是旧版本数据从而避免不可重复读。

       此外cpu瓶颈在软件优化走不下去的时候，也应该考虑升级硬件，更多的核和更高的频率。

       当内存出现瓶颈的时候，也是先考虑是不是代码有问题，比如说数据结构设计的不是很精炼，当然像avl树这样简单的数据结构没有优化空间了。如果存储了大量过期数据或者重复数据的话就要考虑定期释放掉这些数据清理空间。像mysql的话需要考虑参数配置是否有问题，比如sort_buffer_size全局设置的过大，其实根本用不了这么多，但是每次排序依然分配造成浪费。可以通过free和ps或者/proc/${pid}/来查看进程的统计信息。

       当软件方面解决不了就需要升级内存，一般来讲vmstat里的swap交换块次数应该低于5，高了就要考虑加大内存了。

       当硬盘io出现瓶颈时,可以通过iostat查看硬盘io状态，看下每秒读写请求数确定是读造成的瓶颈还是写的问题，如果是的话是周期性问题还是一直持续的io压力，看下每秒扫描扇区看下是不是随机读写太严重了，看下每次服务耗时时长来确定是不是并发量过大的问题。找出可能的问题方向再去寻找造成问题的源头，比如说周期性io负载过高是不是mysql中一次性刷新过多数据，或者一次性提交过多事务导致日志写入量过大，可以通过show variables like ‘innodb%’查看变量设置，也可以show processlist看各个线程的状态，看一下排名前几状态是什么来确定原因。

       当软件优化不起作用时，可以提升硬件，比如说使用raid硬盘阵列，使用ssd等。