接口响应时长几十秒问题排查以及解决

目录

背景

解决方案

总结


背景

     线上系统运行几年后,被项目上提bug,有些接口响应很慢,加载页面要几十秒

解决方案

1、步骤一,加索引

性能优化成本高,需要开发周期,临时方案先分析慢sql,通过增加索引临时解决

效果: 增加索引之后,见效甚微。问题未解决

2、步骤二,分析查询性能

排查sql执行时间,定位是不是mysql服务器问题

mysql查询数据表,总数50w,单sql查询2秒。 mysql没有问题。问题未解决

3、步骤三,导出线上库重现问题

在本地开发库,接口都很快,1秒以内。所以为了重现问题,导出线上数据库表,本地重现以及分析代码。把线上库导入到本地库,执行之后,模拟用户参数,发现接口确实很慢,要几十秒。

找到接口代码,进行分析。发现存在循环,按每查询一次2秒,循环几十次,时间确实吓人

4、步骤四,修改问题

把单个循环查询,改成批量查询。接口就只用查2次数据库,时间控制在5秒

5、步骤五,加缓存(可不做)

如果5秒,还不能满足。可以考虑加缓存,数据查询之后,把数据放入redis缓存,设置缓存过期策略。

总结

接口性能差,可以通过下面几个方面进行优化:

1、分析mysql,加索引

2、清理数据表垃圾数据,减少数据量

3、分析代码,循环多次查数据表,优化成批量查数据表

4、循环多次写数据,改成批量写数据

5、以上都不能满足,考虑加缓存

6、如果数据表数据量达到千万,考虑历史数据保存到es,非历史数据存mysql的方案。进行分库分表等处理

  • 8
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当遇到k8snode节点notready问题时,可以按照以下步骤进行排查解决: 1. 检查节点状态:使用命令 `kubectl get nodes` 检查节点的状态,确保节点处于 `Ready` 状态。如果节点状态为 `NotReady`,则表示存在问题。 2. 检查节点事件:使用命令 `kubectl describe node <node-name>` 查看节点的事件,以了解是否有任何故障或异常情况。 3. 检查kubelet日志:使用命令 `journalctl -u kubelet -n 100` 查看kubelet的日志,以查找任何与节点notready相关的错误或警告信息。 4. 检查容器运行时日志:如果使用的是Docker作为容器运行时,可以使用命令 `journalctl -u docker -n 100` 查看Docker的日志。如果使用的是其他容器运行时,可以查找相应的日志文件。 5. 检查网络配置:确保节点能够与其他节点和控制平面正常通信。检查网络配置是否正确,并确保防火墙规则没有阻止必要的流量。 6. 检查资源使用情况:检查节点的资源使用情况,例如CPU、内存、存储等。确保节点上的资源充足以正常运行Pod。 7. 检查配置文件:检查节点的配置文件,例如kubelet配置文件、节点标签等。确保配置文件没有错误,并且节点的配置与集群的要求一致。 8. 重启kubelet服务:尝试重启kubelet服务,可以使用命令 `sudo systemctl restart kubelet`。重启后,观察节点状态是否变为Ready。 9. 联系硬件供应商:如果怀疑节点故障,例如硬件故障或操作系统崩溃,可以联系硬件供应商寻求支持。 10. 检查其他组件:如果以上步骤都没有解决问题,可以检查其他与节点相关的组件,例如网络插件、存储插件等。 在排查问题时,可以结合使用多个命令和工具,以获取更全面的信息和诊断结果。根据具体的情况,可能需要进一步查找相关文档或寻求社区的帮助来解决问题

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值