服务器性能调优

博主技术偏 C

硬件

如果是硬件瓶颈就换硬件 （包括CPU、内存、网卡、硬盘）

软件

（软件，特指我们写代码的那部分程序）

建议先 top 看下软件瓶颈在哪，CPU、内存、网络（netstat），哪个进程占用比较高

还有硬盘I/O等，一般情况比较少

（有时候可能不是自己代码的问题，也可能是第三方库的问题，需要注意）

CPU

是bug

比如，CPU异常 100%，C程序需要拿 gdb、pstack 工具去调试看看是不是死循环了

不是bug

1、可能需要配合工具（CPU Profile---让函数操作清晰可见 - 知乎）查看函数调用的热点图，看看哪些函数调用比较频繁，结合热点图看看热点函数有没有可以优化的点

2、如果没有优化空间了，看看需不需要分散CPU压力，多线程或者是集群分布式分担压力，参考方案优化

内存

是bug

1、比如内存泄漏（比如我们有个内存监控的网站，我们发现近一个月以来，监控进程服务的内存一直在缓慢上涨，一直没掉下来），C 代码用 valgrind 等工具排查泄漏点

2、结合经验使用 top、free 命令去判断，值得一提的是 top 的 VIRT 是虚拟内存可能略高于实际使用的内存，用代码打印自己占用的内存的日志也是不错的选择。或者是统计进程里内存布局的堆、栈、代码段等占用大小的加和，也能拿到准确的内存占用信息

3、还有一些其他的内存调试工具，比如 asan

不是bug

主要是逻辑错误，工具只能检测能正常释放内存，不能检测逻辑错误，这种只能人工分析

1、比如有些数组申请过长（比如1000），看下是不是能改个800，做一些代码层的优化（这种不属于内存泄漏），可能还需要配合打印日志，比如某个阶段占用的内存

2、在某个程序运行阶段，有些内存不应该被申请，但是也申请了，导致占用不必要的内存，像这种问题比较隐蔽

3、实在没有优化空间，就是参考方案优化

网络

可以先 netstat 看下发送或者接收队列有没有堆积，此外还可以结合抓包定位问题

内部问题

如果是服务器侧问题（是不是我们代码处理并发不太合理），考虑I/O多路复用等

外部问题

和我们对接的客户端流量过高，要不要限制客户端流量，方案是否能做优化（或者分布式分散压力）

中间件

还有一些性能问题可能不是在我们写的程序里面，可能在mysql、redis等中间件里，一般是两种情况，中间件一般都带有自己的调试日志，比如mysql就可以打印慢查询的sql语句，我们可以结合日志和我们代码一起分析

中间件返回时间过长

这个需要结合代码和中间件日志分析，这个比较影响 tps

比如mysql是不是慢查询: 

MySQL慢查询及解决方案_软件开发随心记的博客-CSDN博客

比如mysql是不是索引失效

mysql索引失效的常见9种原因详解_mysql索引失效的几种情况_embelfe_segge的博客-CSDN博客

比如mysql使用insert缓慢，看下是不是索引设置不合理，或者索引太多，维护索引时间比检索时间还长

比如redis是不是有大key存在

Redis中什么是Big Key（大key）问题？如何解决Big Key问题？_redis大key解决方案_每天都要进步一点点的博客-CSDN博客

中间件CPU、内存占用过高

这个需要结合代码和中间件日志分析，这个比较影响服务器整体性能

看下是不是我们代码导致的上诉问题，如果不是的话，就是业务量实在太大，可以考虑优化方案

方案设计

如果软件硬件都优化到瓶颈了，看看是不是方案问题，比如说考虑架构上考虑分布式，通过分布式思想来分散CPU、内存、网络压力，把单一压力打散到各个点上；比如程序上是否可以考虑多进程，多线程方式，反正就是分散压力；中间件也考虑分布式来分散压力