首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >运维系统性能优化后思考,除了避免懒惰的麻木,还需要了解系统的“脾性”

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

作者头像
jeanron100
发布2019-12-24 13:25:32
3590
发布2019-12-24 13:25:32
举报

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

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

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

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

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秒钟,业务逻辑是完全可以接受的,所以我们选择了默认接受,而等到了不得不改的时候,才会去重新审视这个逻辑。

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-12-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档