ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

一次sql优化和业务场景优化的记录

2021-11-08 18:03:48  阅读:133  来源: 互联网

标签:ck 场景 查看 问题 sql 优化 cmp


一次sql优化和业务场景优化的记录:

1.测试场景及问题描述:

–对接cmp容器管理平台,需要将我方系统采集到的容器资源指标信息,以5分钟为颗粒度发送至cmp对应的接口,大致的处理逻辑为:

—原始指标采集,分析,落库;;

—定时任务执行sql查询,并过滤出对应指标,查询出最近5min的结果,(basic_tsdb大宽表,行极多)不到4亿数据

—转化成对应的接口格式,通过接口反馈给cmp系统;

–问题:(1)kafka对应消费组消费堆积;(2)定时任务执行时,sql报错执行超时,影响对应接口获取不到数据

2.分析及解决问题思路:

针对问题(1):

—查看了各节点的消费堆积分布,排除了偏移量不均问题;

—查看了sink(消费者)日志,没有明显报错,排除功能影响导致数据不能入库问题;

—查看了ck(数据库)状态,及磁盘读写负载,没有看到明显瓶颈,排除资源问题;

因此推测为消费能力没有得到完全释放:

故增大了消费者的task属性值(提高消费线程,使task数=topic*partitions数量);

重建了kafka-topic,清除已堆积的数据;

修改了collector(数据收集器)的采集上报频率,由5s增大至1min(求稳);

针对问题(2):

—直接把sql在客户端执行了一遍,30s超时(客户端默认配置),推测为数据库性能问题或sql问题;

—查看sql,没有select*等小白问题,存在字符串转换函数,关联查询,分组,过滤等

—查看数据库cpu使用情况(ck特性为查询默认消耗所在机器一半的CPU核数,功能环境adb未和产品组件拆分部署,存在资源争抢),60%左右,没有达到瓶颈;

—鉴于和开发说了sql问题,他不认,使用了ck的解析计划,分析了sql执行过程:(几乎全表扫描,就查出了35条)

优化前的sql查询效率及过滤数据总行数

优化思路:先通过时间范围和系统id缩小结果集,再过滤全部指标

优化后:优化后的sql查询效率及过滤总行数

标签:ck,场景,查看,问题,sql,优化,cmp
来源: https://blog.csdn.net/weixin_41657942/article/details/121212884

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有