mysql系统分析实战分享

caoz的梦呓 · 公众号 · 科技自媒体 · 2016-10-08 22:02

正文

请到「今天看啥」查看全文

在本地做性能测试，压力测试的时候，我们知道echo 这种语句是基本没有开销的，也不太可能成为一种负载的来源，但这下我们明白了，echo原来不仅仅是php执行输出，也包含了网络传输的时间开销。只有客户端接收到传输内容后，echo执行才结束。

而那天的问题，其实是因为同机房有其他公司服务器被Ddos，导致机房出口拥堵，按理说这只是websever的问题，但因为webserver本身有轮询机制，而且设置的连接数较大，虽然访问较慢，但没有崩溃，而因为php代码里mysql链接没有及时释放，在php执行echo的时间等待较长，导致mysql链接过多崩溃。

知道这个问题，解决就简单了，因为开源系统封装了输出template的对象，我们就在这个对象执行的时候，先执行mysql_close(); 这样只改了一行代码，问题就解决了。

但后来发现出了bug，bug的理由很无厘头，居然部分template 的伪码里有数据库操作，但这个问题解决也简单，因为毕竟这样的场景很少，而且mysql对象也被封装了，我们就在query方法里加了一行代码，如果没有数据库连接，就重建一个。这样，这个重建过程只出现在极少数template里有mysql操作的场景，对整体系统基本没有性能干扰。

这个案例说来挺简单，就是数据库连接没有及时释放造成的，但因为触动了一个思维盲区，所以印象深刻。

线上的程序做断点日志分析是最常用的分析诡异问题的方法。基于断点日志分析，我们可以通过类似二分法，逐步递进直到精确定位具体到每一行代码的执行时间开销。

这里还要提醒一个常见问题，线上环境很多问题是在测试环境里很难重现的，所以遇到诡异问题，应该可以在线上做一些日志分析和代码的调试，当然这样可能会有一定的风险，但很多公司的流程和规范，开发工程师只能在线下测试性能和压力承受能力，针对线上很多现实的问题没有办法完整实测。