运营中心深度学习优化，交互响应提速40%

　　去年四月那会儿，运营中心突然说要搞深度学习优化，开发拍着胸脯说“交互响应能提速四十”，我原以为又是那种PPT上的数字游戏——毕竟前年他们搞过什么“智能调度”，结果把主从延迟干到二十秒，害得我蹲机房重启了三次从库。结果这次还真成了，上周压测的时候，监控曲线跟坐了火箭似的往上窜，开发叼着棒棒糖凑过来：“看，没吹牛吧？”

　　但要说这四十的底气从哪儿来，我觉着得归功于“优胜劣汰”——不是算法层面的，是运维层面的。去年他们刚上线那会儿，慢查询日志能堆满半个磁盘，光是解析那些嵌套了五层的子查询就够喝一壶。后来我实在受不了，直接在运维台装了个脚本，每天凌晨三点抓慢查询，超过五秒的直接杀进程——开发当时跳脚，说“你这是野蛮优化”，结果第二天他们自己改了二十多个SQL，把嵌套全拍平了。现在想想，这算不算“用魔法打败魔法”？

　　风扇一直在转，屏幕上的行数跳得我眼花。开发小王路过问了句“好了没”，我指了指监控：“你看这TPS，比上周高了一倍。”他“哦”了一声，蹲下来看了两秒，突然说：“你们是不是把事务隔离级别调成READ COMMITTED了？”我愣了下——这茬我倒是没注意，之前为了防幻读，一直用的REPEATABLE READ。他掏出手机翻了翻文档：“我们模型训练的时候，发现READ COMMITTED下缓存命中率高不少，可能跟锁粒度有关。”我盯着屏幕上的延迟曲线，突然觉得这四十的提速，可能有一半是拜这行配置所赐。

　　不过话说回来，这“优胜劣汰”也不是万能的。上周三凌晨，主库突然挂了，备份恢复的时候卡在某个事务日志上——我原以为是最新的binlog没同步，结果查了半天发现是三年前的一个大事务，当时开发为了“保证数据一致性”，硬是把一个百万行的更新裹在事务里，现在恢复的时候，MySQL得从头解析这个事务，卡了快二十分钟。运维老张蹲在机柜前抽烟：“这要是在生产环境，早就被用户骂死了。”我盯着屏幕上的“recovering”字样，心想：有些“劣”的代码，可能早该在上线前就被“淘汰”掉。

　　外卖凉了，窗外的天也黑了。开发那边还在调参数，我翻着慢查询日志，突然看到个熟悉的SQL——是去年被我杀过进程的那个，现在居然跑进了前三慢。我喊小王过来：“这SQL怎么又回来了？”他挠挠头：“模型迭代的时候，有些特征需要重新计算，就加了个子查询...”我指着日志里的“Using temporary; Using filesort”：“你们管这叫优化？”他沉默了两秒，突然笑了：“要不...今晚加个班？”

文章配图，仅供参考

　　现在运营中心的交互响应是快了，但我知道，这四十的提速里，有多少是靠“淘汰”慢查询换来的，有多少是靠调整事务隔离级别蹭来的，又有多少是靠运气——比如那个三年前的大事务没在生产环境发作。开发说下周要上新的特征工程，我盯着监控里的连接数，心想：这波优化，怕是要把之前“淘汰”的坑，再重新挖一遍。不过至少现在，风扇转得没那么响了，屏幕上的行数也不跳得那么凶了——这算不算另一种“优胜劣汰”？

　　下一步得盯紧开发的新SQL，尤其是那些带子查询的。另外，备份策略得重新梳理，磁带库的索引文件得找回来，共享盘的权限也得收紧——勒索病毒的事不能再发生第二次。至于那四十的提速能维持多久...谁知道呢？优胜劣汰的规则里，从来就没有“一劳永逸”这一条。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!