bug排查小结

 

mysql cpu利用率偏高,并且长时间居高不下。

show processlist

发现有一个单表查询的sql语句出现的频率比较高,

这个单表查询中规中矩,where语句中条件都使用”=“连接,再加一个order by 语句

解决办法:

把order by 语句中字段加索引,mysql cpu利用率应声下跌。

万能的搜索引擎

cpu利用率高,肯定是线程多喽,查看那些线程比较耗时,优化这些耗时的线程即可

头痛医头,脚痛医脚 也不失为一个好办法

 

时间: 2024-09-19 09:24:05

bug排查小结的相关文章

程序的bug排查流程总结

只要是人写的程序,不可能没有bug,那么解决bug,将伴随程序员的一生: Ø 只会写代码,但不会排查bug的程序员,只能算是业余程序员 Ø 能解决一般bug的,只能算是初级程序员 Ø 代码写的质量较好,还能查找较难bug的,中级程序员 Ø 代码写的质量好,注重性能,不但能排查疑难bug的,还能解决疑难bug的,高级程序员 Ø 代码写的质量好,注重性能,稳定性,可靠性,架构设计合理,能解决绝大部分疑难问题,属于资深程序员 以上的话引自某个论坛网站,不一定说的绝对正确,但基本是有道理的.   面对出

断网故障时Mtop触发tomcat高并发场景下的BUG排查和修复(已被apache采纳)

该文章来自阿里巴巴技术协会(ATA)精选集 目录 现象 NIO模式背景介绍 排查过程 结合业务场景解释问题产生的原因 进一步的发现 解决办法 向Apache社区的反馈 总结 现象 mtop的机器,环境为Ali-Tomcat 7.0.54.2,连接器采用的是NIO模式,在高流量(约1000 qps)的情况下,在Tomcat的启动后一段时间内,抛出ConcurrentModificationException,然后再过一段时间后,Tomcat无法再接受新的请求. 异常堆栈如下: Exception

Apache Jmeter3.0压测数据库OOM的Bug排查

一.引言 Apache Jmeter 2.13(以下简称Jmeter2)版本后,2.X系列就作古了.前些日子,Apache Jmeter 3.0(以下简称Jmeter3)版本正式发布,新生的事物,功能肯定强大了很多,但作为开源产品,稳定性自然要打些折扣,一位同学前几天在使用Jmeter3时不幸中招. 二.问题描述 原本好用的JDBC请求脚本,压测数据库,使用Jmeter3版本时直接OOM,回退至Jmeter2,一切正常,啥也别说,肯定是又出Bug了,本着求实的精神,咱来看看Jmeter3为毛OO

基于IE下ul li 互相嵌套时的bug,排查,解决过程以及心得介绍_javascript技巧

检查bug的步骤 1. bug定位 在js脚本中,按照脚本执行的顺序,你可以用console或alert,来确定bug发生的代码区间,然后在区间内进一步来查找bug发生的具体代码段. 2. bug fix 通过排除,就是在插入节点内容的时候导致了bug,我用的是kissy的DOM.html()方法,其功能类似于DOM元素节点innerHTML方法,我起初认为是这个方法导致的IE6\7渲染出错,然后我换成了innerHTML方法,结果还是有误. 这时候我想到了内存泄露,看看是不是在循环拼接字符串的

tomcat的NIO线程模型源码分析

1 tomcat8的并发参数控制 这种问题其实到官方文档上查看一番就可以知道,tomcat很早的版本还是使用的BIO,之后就支持NIO了,具体版本我也不记得了,有兴趣的自己可以去查下.本篇的tomcat版本是tomcat8.5.可以到这里看下tomcat8.5的配置参数 我们先来简单回顾下目前一般的NIO服务器端的大致实现,借鉴infoq上的一篇文章Netty系列之Netty线程模型中的一张图 一个或多个Acceptor线程,每个线程都有自己的Selector,Acceptor只负责accept

【直播】React、AliSQL、BeeHive、JStorm等8大阿里开源项目最佳实践分享

  本次峰会精选了目前较为活跃的阿里开源项目,其中较为有看点的是:在GitHub上拥有超过一万Star.在阿里内部落地超过400个项目的React 组件库 antd在蚂蚁金服的实践:MariaDB基金会唯一的中国成员详解AliSQL功能特性:已在天猫.喵师傅,天猫家装等App中应用大型iOS项目解耦方法--BeeHive:Android平台页面路由框架ARouter的一手开发经验:开源的 Android 平台上的秒级编译方案.阿里巴巴 Github 下排行前十的开源项目Freeline背后的奥秘

HBase问题诊断 – RegionServer宕机

本来静谧的晚上,吃着葡萄干看着球赛,何等惬意.可偏偏一条报警短信如闪电一般打破了夜晚的宁静,线上集群一台RS宕了!于是倏地从床上坐起来,看了看监控,瞬间惊呆了:单台机器的读写吞吐量竟然达到了5w ops/sec!RS宕机是因为这么大的写入量造成的?如果真是这样,它是怎么造成的?如果不是这样,那又是什么原因?各种疑问瞬间从脑子里一一闪过,甭管那么多,先把日志备份一份,再把RS拉起来.接下来还是Bug排查老套路:日志.监控和源码三管齐下,来看看到底发生了什么! 案件现场篇 下图是使用监控工具Gang

PostgreSQL 在被除数=0时的小纯真和小倔强

标签 PostgreSQL , 被除数=0 , UDF , 自定义操作符 背景 0不能作为被除数,小学就学过的知识. 对于数据库来说,设计严谨,遵循一些基本的原则也是很有必要的. 当在数据库中除以0时,应该如何处理呢? PostgreSQL为例,它具有非常浓烈的学院派风格,你说它你能让你除以0吗? 显然不让,如下: postgres=# select 1/0; ERROR: 22012: division by zero LOCATION: int4div, int.c:719 代码中,我们可以

Tomcat7.0.26的连接数控制bug的问题排查

感谢同事[空蒙]的投稿. 首先感谢@烈元一起排查此问题.今天发现线上一台机器,监控一直在告警,一看是健康检查不通过,就上去查看了下,首先自己curl了下应用的url,果然是超时没有响应,那就开始按顺序排查了: 1. load非常低,2.gc也正常,3.线程上也没死锁,4.日志一切正常.那是什么情况呢,不能忘记网络啊.果然,netstat命令一把,结果如下: TIME_WAIT 68 CLOSE_WAIT 194 ESTABLISHED 3941 SYN_RECV 100 问题出来了,SYN_RE