无挑战,不工作之 -系统分析师招聘答案

| 标签 系统分析师 招聘 答案 

原文地址:http://hi.baidu.com/caoz/blog/item/6020720e81ec12c67bcbe14b.html

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

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

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

思路开阔(dba的问题别死盯着dba,谢谢)

经验丰富,上述列到的,您列出了几个?

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


上一篇     下一篇