从一个论坛上拷来的,debug工具大全,真的挺全,记下来需要时看看! 1.TraceView1)功能:用于热点分析和性能优化,分析每个函数占用的CPU时间,调用次数,函数调用关系等 2)方法:a)在程序代码中加入追踪开关   import android.os.Debug;   ……   android.os.Debug.startMethodTraci
mysql cpu利用率偏高,并且
原创 2022-08-24 18:58:10
97阅读
在日常的Java开发中,代码难免会出现一些“bug”。今天,我想具体聊聊“Java bug排查”的过程,这是一个可能影响项目质量和交付的关键环节。 ### 问题背景 在一次大型电商平台的开发中,我们发现系统在高并发场景下出现了显著的性能下降,用户体验受到严重影响。这一问题的发生,直接导致了订单处理的延迟,进而影响了用户的购买意愿,产生了潜在的经济损失。 可以用以下数学模型描述这个规模问题:
原创 6月前
20阅读
目录2021-03-14 后门接口get请求超时导致重复执行2021-03-14 缓存修改bug------------------修复问题一般步骤:debug 总结:写代码避免bug注意:bug记录BUG1. mutrlpart 临时目录问题   BUG2: JPA中的SAVE问题BUG3: Redis序列化问题2021-04-08 Simpledateformat 线程不
我们测试bug之后,需要自己排查一遍,以确保我们提交的bug是真实存在的。那么如何排查呢? ...
转载 2021-10-17 17:51:00
364阅读
2评论
服务器问题排查步骤一 、cpu使用情况1. top查看总体的系统硬件使用情况2. vmstat 查看cpu3. jstat分析频繁gc二、 内存使用情况1. free 查看内存使用情况2 .使用JMAP定位代码内存泄漏三、 硬盘空间使用情况1. df -lh 查看磁盘的使用情况2. du -h --max-depth=1 查看当前目录中文件和文件夹的大小3.iostat 查看磁盘io情况4. l
转载 2023-09-26 11:13:24
158阅读
日常Bug排查-消息不消费前言日常Bug排查系列都是一些简单Bug排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。Bug现场某天下午,在笔者研究某个问题正high的时候。开发突然找到笔者,线上某个系统突然消费不了queue了。Queue www.rsxedu.com不消费也算是日常问题了。淡定的先把流量切到另一个机房,让问题先恢复再说。消息累积然后就是看不消费的queue到
sql
转载 2021-06-04 17:11:03
193阅读
日常Bug排查-消息不消费 前言 日常Bug排查系列都是一些简单Bug排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。 Bug现场 某天下午,在笔者研究某个问题正high的时候。开...
转载 2021-07-06 09:44:26
150阅读
文章:WinDbg-如何抓取dump文件 命令: cd C:\Windows\System32\inetsrv appcmd list wp 可以查看各个站点的pid
.
转载 2018-08-28 10:14:00
199阅读
2评论
# AI帮助排查bug Java案例 ## 引言 在软件开发过程中,经常会遇到各种各样的bug。当我们遇到bug时,我们需要花费大量的时间和精力来排查并修复它们。然而,有时候bug的原因并不容易找到,特别是当代码非常复杂或涉及多个模块的时候。在这种情况下,人工智能(AI)可以提供一种新的方法来帮助我们排查bug。 本文将介绍一个使用AI来帮助排查bug的Java案例。我们将使用一个简单的示例
原创 2023-09-17 15:40:36
421阅读
Story background   回望2018年12月,这也许是程序员们日夜不得安宁的日子,皆因各种前线的系统使用者都需要冲业绩等原因,往往在这个时候会向系统同时写入海量的数据,当我们的应用或者数据库服务器反应不过来的时候,就会产生各种各样诡异的问题,诸如表现出来就是系统变得巨卡无比,无法使用,或者周期性卡顿,令人发指,用户轻则问候系统全家,重则心脏病发。总而言之每天都脑壳疼!归根到底是我们的应用服务器或数据库服务器因为扛不住流量造成的系统BUG问题暴露,诸如OOM等,呈现出机器的三高,这里说的三高并不是高血脂、高血压、高血糖。而是高CPU,高内存,高NETWORK/IO!(本文只讲述应用服务器,暂不讲述数据库服务器造成的问题)PS:为什么不做压测?石丽不允许呀   Begin Transaction
原创 2019-04-29 15:42:44
380阅读
在软件测试工作中,排查 BUG 是一项既考验耐心又考验方法论的任务。面对复杂的系统和繁琐的业务逻辑,很多测试工程师常常陷入“看似有问题但找不到原因”的困境。本文将结合实际测试工作,分享 5 个排查 BUG 的小技巧,并设置典型使用场景,帮助大家更高效地定位问题。 技巧一:还原最小可复现场景 核心思路 很多 BUG 并不是在复杂的业务流程下才出现,而是隐藏在某个最小输入或极端条件下。通过“还原最小
原创 1月前
221阅读
http://blog.csdn.net/v587_lu/article/details/50515827
转载 2017-03-10 13:40:32
511阅读
 背景公司有个渠道系统,专门对接三方渠道使用,没有什么业务逻辑,主要是转换报文和参数校验之类的工作,起着一个承上启下的作用。最近在优化接口的响应时间,优化了代码之后,但是时间还是达不到要求;有一个诡异的 100ms 左右的耗时问题,在接口中打印了请求处理时间后,和调用方的响应时间还有差了 100ms 左右。比如程序里记录 150ms,但是调用方等待时间却为 250ms 左右。下面记录下当时详细的定
转载 2021-03-18 17:27:15
86阅读
2评论
简介: 公司有个渠道系统,专门对接三方渠道使用,没有什么业务逻辑,主要是转换报文和参数校验之类的工作,起着一个承上启下的作用。最近,在优化接口的响应时间,优化了代码之后,但是时间还是达不到要求;有一个诡异的 100ms 左右的耗时问题,在接口中打印了请求处理时间后,和调用方的响应时间还有差了 100ms 左右。比如程序里记录 150ms,但是调用方等待时间却为 250ms 左右。本文记录了当时详细
转载 2021-03-18 17:34:54
107阅读
2评论
简介: 公司有个渠道系统,专门对接三方渠道使用,没有什么业务逻辑,主要是转换报文和参数校验之类的工作,起着一个承上启下的作用。最近,在优化接口的响应时间,优化了代码之后,但是时间还是达不到要求;有一个诡异的 100ms 左右的耗时问题,在接口中打印了请求处理时间后,和调用方的响应时间还有差了 100
转载 2021-03-16 11:02:00
159阅读
公司有个渠道系统,专门对接三方渠道使用,没有什么业务逻辑,主要是转换报文和参数校验之类的工作,起着一个承上启下的作用。最近,在优化接口的响应时间,优化了代码之后,但是时间还是达不到要求;有一个诡异的 100ms 左右的耗时问题,在接口中打印了请求处理时间后,和调用方的响应时间还有差了 100ms 左右。比如程序里记录 150ms,但是调用方等待时间却为 250ms 左右。本文记录了当时详细的定位 & 解决流程(其实解决很简单,关键在于怎么定位并找到解决问题的方法)。
原创 2021-03-15 17:24:39
787阅读
作者 | 空无 来源 | 阿里巴巴云原生公众号背景公司有个渠道系统,专门对接三方渠道使用,没有什么业务逻辑,主要是转换报文和参数校验之类的工作,起着一个承上启下的作用。最近在优化接口的响应时间,优化了代码之后,但是时间还是达不到要求;有一个诡异的 100ms 左右的耗时问题,在接口中打印了请求处理时间后,和调用方的响应时间还有差了 100ms 左右。比如程序里记录 150ms,但是调用方等待时间却
转载 2021-03-16 21:05:03
192阅读
2评论
线上故障主要会包括 CPU、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的,基本上出问题就是 df、free、top 三连,然后依次 jstack、jmap 伺候,具体问题具体分析即可。CPU一般来讲我们首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原
前些天发现:http://hellojava.info/ 这个站点,关于java问题排查分析总结线上故障总结其实是最有价值的,好的总结就是一个系统演进历史,是团队难得的积累沉淀。花了不少时间看了下,顺手整理了笔记: 1. Hashmap 并发情况下未加锁导致OOM      嗯,死循环很常见,OOM也会有,序列化时 HashMap.writeObj
转载 2023-07-13 15:31:06
53阅读
  • 1
  • 2
  • 3
  • 4
  • 5