无挑战，不工作

题目：

题目1 很简单，某mysql数据库服务器A，出现mysql链接过多，导致前端web服务器无法打开数据库连接，现在，由你来解决这个问题。

题目1之问题1：你会以怎样的步骤来处理这个事情。请注意，步骤

题目1之问题2：如何分析这一问题，共有几种可能性，每种可能性的分析方式，判别标准是什么。

题目1之问题3：针对不同可能性，给出尽可能完整的解决途径。

不要告诉我您会修改mysql链接参数，如果您只想到这一条，不要来信了。

题目2： 某linux服务器平时负载很轻，cpu在10%-20%之间，但是每周都会有几天在不定时间突然跃升到100%，然后导致该服务器拒绝一切响应（包括ssh链接在内），无奈之下只能电话通过机房重启。

现在，负载飙升时无法连接ssh，暂时无法确认负载飙升原因，请给出你想到的处理步骤和解决思路。

不要告诉我您会设置一个24小时短信提醒，那是最基本基本的了。

题目3：某linux 服务器一直负载很轻，但是会突然拒绝正常的服务，此时仍然可以登录，仍然看到在线很轻的负载，请告诉我你分析排查的思路。

参考答案：

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各项内核参数必须有深入了解，有时候你看服务器跑不动了，可能改一下参数马上就好了，但是改哪个参数，怎么改，这就只能是经验和搜索技巧了。

其实caoz想到的也不完整，后来有人给caoz很多提醒，比如前端mysql,memcache链接应该设置超时参数云云。不过总体来说

意识到位（先临时处理立即恢复线上应用，再彻底处理，处理要评估并且做出预判，优化与故障自动处理要并行，不能100%依赖优化结果）

思路开阔（dba的问题别死盯着dba，谢谢）

经验丰富，上述列到的，您列出了几个？

答案就此公开，谢谢各位的来信。真有不少人才，让caoz兴奋！

来自：http://hi.baidu.com/caoz/blog/item/6020720e81ec12c67bcbe14b.html