运维系统性能优化后思考，除了避免懒惰的麻木，还需要了解系统的“脾性”...

本文主要是介绍运维系统性能优化后思考，除了避免懒惰的麻木，还需要了解系统的“脾性”...，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

这是学习笔记的第 2174 篇文章

读完需要

分钟

速读仅需2分钟

做了一些优化之后，发现系统和人其实蛮像，当然人要高级的多。

很多业务系统在发生问题的时候感觉是突然发生的，但是按照分析问题的思路查下去却发现是这样那样的原因，毫无疑问大多是一些很小的问题逐步放大之后看到的。

近期我们的运维系统的小问题不少，在这个过程中大家有点感觉到了运维系统的老态龙钟，初期关注功能实现，后期关注性能，其实这种方式会让你不断的走一些重复的老路。

近期运维系统常见的问题有：

1）有时候和外部系统进行接口数据推送的时候，会因为API层的异常导致数据通信失败，报错信息类似Broken Pipe,IOError这种，但是没有明细的错误信息。

2）运维系统有时候会突然奔溃，等发现的时候基本是被动的处理方式

3）在某一天做一条简单的DML操作的时候，数据库竟然给我返回执行了5秒

4）近期的业务变更需求比较多，时不时会拆东墙补西墙的发布一些补丁

而这个问题在近期达到了一种常态，那就是每天都会出点问题，这个问题引起了我的关注，我们做出了一些改变。

1）对于系统的服务可用性，我们加入了系统层的monitor模块，这样在服务自动宕机之后，会自动拉起服务。

2）排查了近期的业务需求变更，暂未发现一些明显的性能隐患

3）从磁盘空间增长情况来看，也没有产生一些异常的日志。

从问题的反馈频度来看，大家会逐步对于系统失去信心，同时也会无形中加大各方的业务处理压力。

在经过排查，我定位到问题的瓶颈主要在API层，所以在API层入手来查看是否有一些超时处理的流程。

有一个流程引起了我的注意，我抓取了这个逻辑的SQL情况。

这是一个慢日志进行稽核回写的逻辑，会把收集到慢日志信息进行慢日志个数统计后回写到一个新的表中。

数据库层面进行排查和分析，发现都指向了这个逻辑处理。

也就意味着这条SQL如果进行了完善的优化，那么整个性能问题的90%以上的瓶颈都能够解决。

在这种情况下我进行了进一步的优化，而优化思路其实就是采用增量变更而非全量变更，采用这种方式之后，优化的效果从原来的分钟级下降到了0.2秒左右。

整个过程涉及几个索引的重构和SQL逻辑的优化，难度其实不大。

我在思考这样两个问题

1）为什么这个问题到了现在才被重视？

2）为什么这个问题到了现在才能够被优化？

说到底，里面涉及的主要就是懒惰，就是对于问题的忽视，导致问题由小变大，从一个小的设计问题变成一个大的问题甚至故障，而另外一个层面就是我们需要了解一个系统的“脾性”，正如我在开头说到，系统和人有些类似，有时候我们能够容忍一些，但是如果容忍不了就会爆发，对于系统也是如此。

如下是这条SQL的执行时长的趋势图。

可以看到在近几个月里的执行时长是逐步增长。但是每隔一段时间就会有一些明显的下降，从我的记忆来看，那是我对一些历史数据做了清理，对一些索引进行了构建，但是解决的是一些表面问题，如果我忘记了清理历史数据或者索引的重构效果不佳，那么问题就依然存在，而等到了爆发的一个点，这个问题就是以点带面的影响方式，所以初步来看，这个系统的容忍时间是60秒，但是我们能够优化到0.3秒，听起来确实是很讽刺。

什么样的方式能够解决这个问题，一种行之有效的方式就是能够提出更高的要求和标准，比如现在执行10秒钟，业务逻辑是完全可以接受的，所以我们选择了默认接受，而等到了不得不改的时候，才会去重新审视这个逻辑。

而进一步思考，如何进行问题的规范和完善，我觉得：设定相关的标准和规范流程，同时在这个过程中进行问题跟踪和回溯。

QQ群号：763628645

QQ群二维码如下，添加请注明：姓名+地区+职位，否则不予通过

订阅我的微信公众号“杨建荣的学习笔记”，第一时间免费收到文章更新。别忘了加星标，以免错过新推送提示。

近期热文

你可能也会对以下话题感兴趣。点击链接就可以查看。

华裔教授发现二次方程极简解法,我默默的做了下验算
MySQL的主键命名挺任性，就这么定了
回答:我不小心把公司的数据库给删了，该不该离职？
迁移到MySQL的业务架构演进实战
数据库修改密码风险高，如何保证业务持续，这几种密码双活方案可以参考
MySQL业务双活的初步设计方案
如何优化MySQL千万级大表，我写了6000字的解读
一道经典的MySQL面试题，答案出现三次反转
业务双活的数据切换思路设计（下）
业务双活的数据切换思路设计（一）
MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意
小白学MySQL要多久?我整理了10多个问题的答案