有关“架构师”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

案例2：看似正常的负载过高

当时有个新业务数据增长很快，该业务的数据库服务器每天处理数百万次数据查询请求，uptime比较高，经常在5-6的样子，cpu负荷较重，运维负责人就发邮件，申请更换更好的服务器，增加资源。

按理说，这是个合理请求，负载也确实很高，业务也确实增长，但我这个人天性财迷抠门，总觉得这个数字不应该是极限，就登录到数据库服务器看了一下，很简单，我的方法就是先刷show processlist，连续刷几遍，看数据库都在执行啥，开销都集中在什么状态，这一看还真就发现问题了，居然经常看到有些mysql进程停留在 storing result to query cache 上。

这事我就纳闷了，因为按常规，这个状态应该是基本没有时间开销的，也就是show processlist看到是小概率事件的。

所以就要验证一下，执行 set profiling=1，然后从show processlist复制一条执行一次，然后执行 show profiles for query 1;  结果意外发现，常规来说执行开销最大的sending data （这个开销可不是输出数据哦，其实是io寻址）只有0.002秒，而 storing result to query cache 却执行了 0.005秒的样子，千分之五秒，一般人可能就无视了吧，但整个SQL执行不到0.01秒，这个开销比例蛮大的了。

那个，其实这个问题的责任者呢，是我自己，我觉得query cache是个好东西啊，所以开始配置服务器的时候，还是我自己做的配置，因为服务器内存够大，我就把query cache设置的比较大，结果SQL的反馈结果内容较多的情况下，就出现了query cache的碎片化比较严重，反而导致了query cache存储额外的开销，我在数据库里直接操作将query cache内容重置的命令，再执行这个SQL，用profiling去分析，发现这个开销就没有了，负载瞬间显著下降了60%左右。

然后我跟运维负责人说，半夜没人的时候把数据库的启动参数，query cache那块设置回默认值，重启一下数据库，于是就没再追加预算和服务器投入。