,但是如果不去估算,那么永远都没有经验,永远估不准,这其实也是意识。
但是到了这里,事情还不算完,还有一步!
第四步是什么呢?无人值守脚本
千算万算,不能不算,无人值守情况下,数据链接过多怎么办,有几种解决方案,重启数据库未必明智,一个很简单的原因,如果是myisam,重启可能导致数据索引出错,如果是innodb,可能重启需要很长时间,最有效的,还是直接kill掉阻塞的查询进程。然后记录日志以备后续分析。
而且,按照caoz的经验,不要等链接阻塞再去kill掉
查询进程,应该在链接数超过报警阈值的时候直接kill掉执行时间过长的SQL查询进程,有人会问,哪里有这样的系统?自己写一个cron脚本,花不了一个小时的。
第二个问题,在上头啰啰嗦嗦有罗列
第三个问题,场景很多,简单列如下
1:数据库读写锁,换成innodb引擎是最快的方法,那么读写分离做主从也是一种
方案,不过要考虑成本还是蛮高的。此外就是读取数据多用缓存,写入过多怎么办?也用缓存!缓存回写,同主键写入合并,具体策略不多说了,这是caoz看家的本事。
2: sleep链接太多,前端代码检查,找到关联影响点,尽快释放
mysql链接
3: 慢查询和准慢查询太多,索引优化,以及数据库拆分优化(忙闲拆分,主键hash拆分,还有其他拆分模式),索引碎片整理(数据索引优化或重建,半夜偷偷干吧)
4:
网络阻塞,减少控制数据库操作的数据流量,改代码去吧
5:i/o
压力过大,有些参数可以设置的,比如innodb的数据提交不一定每次操作都提交的。
总之,优化方案之多,难以全面罗列,可以整理如下
优化分为架构优化,比如引入缓存层,引入主从架构,引入中间件,分库分表,都属于架构优化。
代码优化,减少重复和不必要的查询,合并重复查询,良好的代码习惯
DBA优化,索引优化,存储引擎优化,my
sql参数优化,数据库版本优化
操作系统优化,文件系统优化,linux内核优化,
对系统架构的理解,有助于从不同层面分析问题,思路要发散,不要只看数据库
对数据查询的理解,多使用set profiling,对每一个停留状态,每一个耗时和资源分配,索引的每一次查询方式要心理有数。
对数据库参数的理解,要知道每个参数对i/o的影响,对查询执行的影响,对每个SQL进程执行步骤(set profiling可以分析SQL执行步骤)的影响是什么,
对
程序的理解,要知道程序为什么请求数据,请求数据的目标和方法是否合理,是否有重复和无效的请求占用资源。请求数据后是否长期闲置链接,是否存在不合理的关联影响。
对系统的理解,是否存在系统配置短板,导致数据库性能无法发挥。
第二题
简单说,关键是无人值守脚本,无人值守脚本要
1:记录负载提升时的
系统状态和进程
列表,进程资源占用数据。
2:自动对突然增加负载的用户或系统进程进行处理,
3:记录处理结果和处理后的状态。
无人值守记录是系统维护的关键点,有很多人用第三方工具,当然很好,但是必要的时候必须亲自做一些监控脚本,这东西用什么写都可以,php,perl,ruby都无所谓,能记录,能执行关闭进程和启动进程的操作就可以。
第三,这种问题当然有很多种可能,分析日志也好,分析系统状态也好,不过根据caoz经验,出这种问题,80%以上是系统某参数越界,这种越界还蛮多的,比如最多文件打开数,系统最大连接数,syn_backlog,甚至最多文件节点数(看硬盘空间还有,其实inode没有了,大量琐碎小文件就会出这个问题!)还有,ip_contrack什么参数,可能导致网络丢包严重,所以这个问题的关键是,对
linux各项内核参数必须有深入了解,有时候你看服务器跑不动了,可能改一下参数马上就好了,但是改哪个参数,怎么改,这就只能是经验和
搜索技巧了。