客户端

检查网络连接

客户端是否连接本身不够通畅，可以访问一下其他网站是否反映较慢，如果也比较慢，可能是客户端当时网络环境不好。

检查DNS

使用ping命令排查是否是dns服务器发生故障，如果ping 域名本身发生连接不通的情况，可能是dns服务器发生宕机，不过这种可能情况比较少。

检查代理服务

检测本地是否是受到其他代理服务器影响。

服务器端

检查带宽

从服务器监控后台查看是否服务器出口带宽已经完全占用，这是一个很常见的服务器瓶颈。尤其是在访问高峰的时候非常容易出现， 对于这个问题，可以通过提高网络出口带宽解决。

检查服务器CPU或者内存

服务器CPU或者内存消耗过大，这个问题基本上就是比较复杂的了，通畅要从系统本身的环境来分析，可能有这样的一些情况，比如拿PHP的LAMP架构来分析，可能会有以下点。

1. nginx本身的连接数(max_clients)已经占满(这个值的计算与worker_processes和worker_connections有关，具体可以参考https://www.cnblogs.com/tangchuanyang/p/6076725.html)。然后通过命令ps -ef | grep nginx | wc -l来查看正在运行的nginx进程数量(更多统计可以参见https://www.cnblogs.com/centos-python/articles/8522286.html)，

对比看看是否nginx设置的数量过高占用cpu还是设置过低已经被完全占满。

2. 检查fpm是否已经占用数量过大，一般来说由于nginx是异步非阻塞的，所以nignx上面一般不会是发生瓶颈的点，其中比较重要的是max_children和max_request这两个值(具体作用可以参见https://www.cnblogs.com/ahaii/p/5776809.html)。

3. 程序本身的执行效率问题，比如可能程序写了一个死循环，导致内存耗尽，或者类似于程序再做大量的导入导出操作等，都可能消耗cpu或者内存资源。这种可以做业务拆分，将不同的业务放到不同的服务器上面。

MySQL的性能瓶颈

这个是最后可能出现缓慢的地方，因为MySQL一般是磁盘的I/O操作，这个是远远慢于内存操作的。原因可能有以下一些。

1. MySQL在大量连表查询或者出现大量数据检索使用的索引不当造成缓慢查询，甚至有些SQL要在分钟级别才这种能完成相应。这种情况要适当做好SQL的慢查询监控，可以通过慢查询日志来监控(也可以通过show processlist;来查看当前状态下面的执行语句)，然后对慢查询出来的SQL进行分析优化(如大家都知道的explain分析工具)。

2.分析数据库是否存在死锁(常见场景可以参考https://www.cnblogs.com/LBSer/p/5183300.html)，出现死锁的直接结果就是系统卡顿、客户找事儿，所以我们也在想尽全力的消除掉数据库的死锁。出现死锁的时候，如果只是想解锁，用show full processlist看下kill掉就好了，如果想查找到详细的问题，一个办法是用show engine innodb status来查看简略信息或者开死锁日志，后期在mysql日志里面慢慢分析。MySQL 5.5 版本以后，information_schema（ski:m?） 库中新增了三个关于锁的表，亦即 innodb_trx 、innodb_locks 和 innodb_lock_waits 。其中 innodb_trx 表记录当前运行的所有事务，innodb_locks 表记录当前出现的锁，innodb_lock_waits 表记录锁等待的对应关系。可以通过这些寻找答案。不过一般出现锁的情况都是程序引起了的，都可以通过优化代码和架构来解决(可以参考https://www.cnblogs.com/likui360/p/5856114.html)。

最后

其实说这么多，事后寻找问题是不太靠谱的，对于高可用的系统来说，做好实时监控才是最有效的方式，如果能够及时给出服务器、数据库之内的异常报警信息是最好的了。而且某种程度上说，这种投入是必要的。

好了，今天的内容就给大家谈到这里！

更多精彩，欢迎关注公众号：编程社