[转]caoz写的关于系统分析的文章

原帖地址：点击 留作个人收藏之用

 

caoz考核，一看意识，二看思路，三看方法

前言 ： 其实考试这种东西本身是不平等的，因为出题人肯定有优势，所以有些人水平比caoz高很多，答caoz的题目也只能得到七八十分而已，如果换过来出 题，caoz可能及格都是问题，而且这些题目其实更适合面试进行，因为可以层层递进剖析问题，从一个大问题引申提出更多子问题，这是caoz面试常用的习 惯，很多趾高气扬的人进来，灰头土脸的出去，当然，还是那句话，考核本身是不平等的。也许您答的和caoz期望的相差不少，但是不代表caoz比你水平 高。

回过头来说，意识是第一位的

1:数据链接过多，这是最常见的问题，但是其实也是这里最重点的问题

子问题1，为什么提到步骤，很少有人告诉我，第一步是尽快临时恢复线上应用，这就是意识！

恢复线上应用有几种场景，最简单的是show processlist 然后kill掉阻塞的processlist，其次是重启数据库，如果数据库重启后又会快速堵塞，那么要尽快从前端代码中找到阻塞点，临时屏蔽掉某些导致 阻塞的功能，以及增加同时链接参数，为了保证在你彻底解决这个问题的这段时间里，你的前面网页是可以顺利打开的。

这里存在一个小问题，如果是面试我会单独提出来，你怎么保证连接过多的情况下，后面还能看到show processlist，这里的窍门是，前段务必不要使用root连接数据库，这样mysql后端root仍然会多出一个进程来满足查询要求。 之前我跟工程师说这个问题，他们果然换了一个账号，一个不叫root但是权限是root的账号在前端连接数据库，害的我郁闷了n多天找不到阻塞点。

第二步是确认阻塞点和阻塞方向，为什么说阻塞方向，因为数据库的阻塞，并不一定都是数据库造成的，连带影响非常多，通过show processlist ，如果看到大量的Lock，那么其一是代码优化，其二是改造数据引擎，如果Lock不多，而执行中查询很多，其一是索引优化，其二是数据库参数优化，有人 说会看慢查询，慢查询很重要，但是不够的，对于高并发来说，一个常见SQL执行0.1秒都是不可容忍的，通常这是索引不彻底造成的，比如简单来说 ，如果有个同城速配的常见SQL select * from users where sex='女' and area='厦门' order by lastlogin desc ，这么一个查询，你会怎么建立索引？我告诉你，三键复合索引！少一个效率都不行. 而且顺序还必须保证！ 之前非常多发现因为复合索引不到位，导致数据查询执行0.05 -0.1秒的准慢查询，通过set profiling是可以分析的，优化后效率提升10-100倍。 此外，连带影响也是一个大问题，比如说，有时候你会看到大量SLEEP链接，那多半是前段执行完SQL没有及时关闭，之前我的博客如果有认真阅读的，会看 到因为echo影响，因为memcache链接阻塞影响都会存在，当然还有一种，网络带宽阻塞影响，Waiting for net状态阻塞，

这里确认阻塞点和阻塞方向，最关键的是思路要足够发散，不要只看数据库配置，或者数据索引；前端程序，网络环境（曾经因为别人的外挂程序，以及代码 不严谨，导致内网网卡阻塞，数据库连接过多）都需要考虑周全，所以有些答案caoz回复说思路不开阔，就是这个原因。这里具体分支场景很多，caoz也只 是列举一二，仅仅配置优化，就有无数参数可以提出。

第三步是解决，这里通常要多向考虑，什么叫多向考虑，分析问题如果够全面，就会发现问题往往是伴生出现，比如出现阻塞，也许你优化后台参数的确可以 解决，但是如果前端调用脚本也优化一下，可能就会得到更好的效果，那么这里要强调的是，解决问题必须给出明确的数字支持，比如升级后，性能提升多少，负载 支撑提升多少，可支持多少并发，支持多少同时连接，由于经验问题，很多人估算不准，这不是问题，几次训练下来就准了，但是如果不去估算，那么永远都没有经 验，永远估不准，这其实也是意识。

但是到了这里，事情还不算完，还有一步！

第四步是什么呢？无人值守脚本

千算万算，不能不算，无人值守情况下，数据链接过多怎么办，有几种解决方案，重启数据库未必明智，一个很简单的原因，如果是myisam，重启可能 导致数据索引出错，如果是innodb，可能重启需要很长时间，最有效的，还是直接kill掉阻塞的查询进程。然后记录日志以备后续分析。

而且，按照caoz的经验，不要等链接阻塞再去kill掉查询进程，应该在链接数超过报警阈值的时候直接kill掉执行时间过长的SQL查询进程，有人会问，哪里有这样的系统？自己写一个cron脚本，花不了一个小时的。

第二个问题，在上头啰啰嗦嗦有罗列

第三个问题，场景很多，简单列如下

1：数据库读写锁，换成innodb引擎是最快的方法，那么读写分离做主从也是一种方案，不过要考虑成本还是蛮高的。此外就是读取数据多用缓存，写入过多怎么办？也用缓存！缓存回写，同主键写入合并，具体策略不多说了，这是caoz看家的本事。

2： sleep链接太多，前端代码检查，找到关联影响点，尽快释放mysql链接

3： 慢查询和准慢查询太多，索引优化，以及数据库拆分优化（忙闲拆分，主键hash拆分，还有其他拆分模式），索引碎片整理（数据索引优化或重建，半夜偷偷干吧）

4： 网络阻塞，减少控制数据库操作的数据流量，改代码去吧

5：i/o压力过大，有些参数可以设置的，比如innodb的数据提交不一定每次操作都提交的。

总之，优化方案之多，难以全面罗列，可以整理如下

优化分为架构优化，比如引入缓存层，引入主从架构，引入中间件，分库分表，都属于架构优化。

代码优化，减少重复和不必要的查询，合并重复查询，良好的代码习惯

DBA优化，索引优化，存储引擎优化，mysql参数优化，数据库版本优化

操作系统优化，文件系统优化，linux内核优化，

对系统架构的理解，有助于从不同层面分析问题，思路要发散，不要只看数据库

对数据查询的理解，多使用set profiling，对每一个停留状态，每一个耗时和资源分配，索引的每一次查询方式要心理有数。

对数据库参数的理解，要知道每个参数对i/o的影响，对查询执行的影响，对每个SQL进程执行步骤（set profiling可以分析SQL执行步骤）的影响是什么，

对程序的理解，要知道程序为什么请求数据，请求数据的目标和方法是否合理，是否有重复和无效的请求占用资源。请求数据后是否长期闲置链接，是否存在不合理的关联影响。

对系统的理解，是否存在系统配置短板，导致数据库性能无法发挥。

第二题

简单说，关键是无人值守脚本，无人值守脚本要

1：记录负载提升时的系统状态和进程列表，进程资源占用数据。

2：自动对突然增加负载的用户或系统进程进行处理，

3：记录处理结果和处理后的状态。

无人值守记录是系统维护的关键点，有很多人用第三方工具，当然很好，但是必要的时候必须亲自做一些监控脚本，这东西用什么写都可以，php,perl，ruby都无所谓，能记录，能执行关闭进程和启动进程的操作就可以。

第三，这种问题当然有很多种可能，分析日志也好，分析系统状态也好，不过根据caoz经验，出这种问题，80%以上是系统某参数越界，这种越界还蛮 多的，比如最多文件打开数，系统最大连接数，syn_backlog，甚至最多文件节点数（看硬盘空间还有，其实inode没有了，大量琐碎小文件就会出 这个问题！）还有，ip_contrack什么参数，可能导致网络丢包严重， 所以这个问题的关键是，对linux各项内核参数必须有深入了解，有时候你看服务器跑不动了，可能改一下参数马上就好了，但是改哪个参数，怎么改，这就只 能是经验和搜索技巧了。