学习
实践
活动
专区
工具
TVP
写文章

死锁问题排查

问题背景 最近有同事说平台的某个服务出现超时异常,让我帮忙看下原因。我进入平台后触发了该服务,并没有发现超时异常,那可能是在特定操作场景下会出现或者是一个非必现问题。 既然已知道异常服务,那可以从这里入手进行分析,又与同事沟通一番,确定了与该服务相关的一些后台模块,接下来重点排查这些模块。 下面是出现问题的参考日志,关键点已包含其中,因为原日志不方便展示。 排查方法 日志中出现了sync. 问题本质 上面问题的根因是死锁导致的,死锁也是计算机中常见出现的问题。 往往改动代码引发的死锁问题比较容易出现,像本文中出现的问题就是代码改动导致的,添加功能需求的时候关注点集中在了业务逻辑上,容易忽视锁的问题

12610
  • 广告
    关闭

    热门业务场景教学

    个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程,多款云服务器20元起。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    日常问题排查-调用超时日常问题排查-调用超时

    日常问题排查-调用超时 前言 日常Bug排查系列都是一些简单Bug排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。 Bug现场 这次的Bug是大家喜闻乐见的调用超时。 开始排查 那么这5秒钟时间到底消失在哪里呢?有3个可能的点: 1)A日志打点到真正发出请求包 2)网络上 3)B真正接收请求包到B日志打点。 可是这又引入了一个新的问题,为什么一次Full GC能达到6s之巨。 为什么这么慢 观察监控,笔者发现Full GC有时候快有时候慢。翻出对应6s的那条gc监控日志。 所以看上去是概率上出现GC慢的问题。 另一个机房没出问题 这时候巧的是,业务开发向笔者反映,另一个机房的相同应用确不会出现此问题。捞了下对应日志,发现其class unloading只有0.9s左右。 另外, 对于一个偶发性的问题,我们应该通过监控等手段去寻找规律,这样就很容易找到突破点。

    16930

    502问题怎么排查

    反过来,如果是服务器有问题,就返回5xx状态码。 4xx和5xx的区别 但问题就来了。 服务端都有问题了,搞严重点,服务器可能直接就崩溃了,那它还怎么给你返回状态码? 这种情况几乎都是程序有代码逻辑问题,崩溃一般也会留下代码堆栈,可以根据堆栈报错去排查问题,修复之后就好了。比如下面这张图是golang的报错堆栈信息,其他语言的也类似。 实例已经销毁但配置没删IP 要排查这种问题也不难。 这个时候,你可以看下nginx侧是否有打印相关的日志,看下转发的IP端口是否符合预期。 如果发现502,优先通过监控排查服务端应用是否发生过崩溃重启,如果是的话,再看下是否留下过崩溃堆栈日志,如果没有日志,看下是否可能是oom或者是其他原因导致进程主动退出。 如果进程也没崩溃过,去排查下nginx的日志,看下是否将请求打到了某个不知名IP端口上。 ---- 最后 最近原创更文的阅读量稳步下跌,思前想后,夜里辗转反侧。 我有个不成熟的请求。

    9920

    Android 混淆问题排查

    问题 近期在开发过程中,突然出现混淆后程序出现运行时异常,编译是正常的,不混淆也是正常的, 错误信息如下提示 12-07 14:10:27.056 10603-10603/? ZygoteInit.java:888) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:749) 思路 1、通过上面的错误信息首先会去排查 2、考虑到关闭混淆正常,开启混淆异常,那么就定位到时混淆的问题 3、既然是混淆问题那就查看混淆配置文件proguard-rules.pro,基本的配置都已经防混淆了 4、接下来的思路就是通过反编译来查看 BaseApplication到底出了啥额问题 过程 第一步 我们看到下面反编译的代码 ? 所以以后遇到混淆的问题就按照提示一步一步排查,一定要反编译文件来分析问题,不然无法定位原因。 还有第一次混淆后建议反编译查看一下包里面的代码,有没有需要混淆的核心代码被keep掉了。

    1.5K20

    线上问题排查总结

    线上问题排查总结 Cpu飙高可能的原因 CAS自旋 没有控制自旋次数;乐观锁 死循环----cpu飙高的问题;控制循环次数 云服务器redis被注入挖矿程序;端口像公网暴露;Redis端口不要被外网访问 } },"晓果冻").start(); } } 指定线程名称 创建新的线程的时候最好指定它的名称不然默认的都是Thread-0、Thread-1这样的,指定名称,在排查问题时也方便在直接在项目 中搜索是哪段代码出了问题。 Linux环境下排查cpu飙高的问题 先模拟一种死锁的情况,让cpu飙高 /** * @author 晓果冻 * @version 1.0 * @date 2021/6/23 7:45 */ public 进程号改变是因为我又重启了程序 通过打印出的信息可以在代码中搜索晓果冻线程名来查询到底是哪段代码出了问题

    7230

    实战网络问题排查(六) -- 利用 wireshark 排查 TCP 空窗口问题

    引言 上一篇文章中,我们看到了如何通过 wireshark 排查 TCP 重复 ACK 特别是由此引发的快速重发问题: 实战网络问题排查(五) -- 利用 wireshark 排查 TCP 快速重传问题 本文,我们就来利用 wireshark 来排查和定位 TCP 滑动窗口协议相关的问题。 2. 这一情况下,无需进行处理,只需检查导致先前零窗口问题的原因。 TCP接收方频繁更改窗口大小。该情况下检查接收方被干扰的原因。可能是应用问题、内存问题、或者终端设备上的其他问题问题排查 如下图所示,是一个典型的空窗口问题的例子: 报文 183816 是 192.168.2.138 在 192.168.1.58 窗口占满之前的最后一条数据,因此被标记为 TCP WindowFull 除了检查内存分配以外,很有可能问题出在接收方处理能力不足,可以结合实际业务进一步进行排查

    86220

    mysql问题排查实例

    帮忙一起定位原因,最后定位到的问题说起来真的是很小的细节问题,但是就是这些小细节导致了服务不稳定,真是细节决定成败。这里尝试着来分享下,希望对大家有所帮助。 问题 1:占着茅坑不拉屎 遇到问题首先要看的还是服务器错误日志。 ,后来仔细读了 node-mysql 的文档及这个 issue,终于发现了我们的写法是有问题的。 问题 2:一条 UPDATE 引发的血案 我们再次查看了错误日志,发现了另一个异常报错:Error: ER_LOCK_WAIT_TIMEOUT: Lock wait timeout exceeded; 问题产生的原因可以这样来描述了:我们在执行 UPDATE 语句时,MySQL 会将其当成一个事务,对表的行进行锁定,这时又有其他连接进来要 UPDATE 同样的表或者 SELECT 这张表时就必须等待锁资源

    51220

    线上问题排查神器 Arthas

    线上问题排查神器 Arthas 之前介绍过 BTrace,线上问题排查神器 BTrace 的使用,也说它是线上问题排查神器。都是神器,但今天这个也很厉害,是不是更厉害不好说,但是使用起来非常简单。 如果你用 BTrace 的话,需要事先写好探测脚本,然后上传到需要排查问题的服务器,然后执行命令。比方说获取某个方法的参数、返回值、异常等。 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现! 是否有一个全局视角来查看系统的运行状况? 正式交互开始,就到了大展拳脚的时候了,线上出现的问题基本上都可以找到合适的命令。 下面简单的介绍几个,就是为了演示一下使用方式。 另外,无论是 Arthas 还是 BTrace ,都是用来排查单机服务问题的,也就是应用内部的代码、性能问题,如果要排查不同服务之间的调用问题,那就是另一个维度上的事儿了。就需要 APM 的帮助了。

    49530

    关注

    腾讯云开发者公众号
    10元无门槛代金券
    洞察腾讯核心技术
    剖析业界实践案例
    腾讯云开发者公众号二维码

    相关产品

    • 云数据仓库 for Apache Doris

      云数据仓库 for Apache Doris

      云数据仓库Doris(cdwdoris)为您提供基于 MPP(大规模并行处理)架构的云端Doris托管服务,拥有开箱即用,弹性易扩展等特性。云数据仓库 Doris支持标准SQL语言,兼容MySQL协议,支持对PB级的海量数据进行高并发查询,和亚秒级的快速分析,帮助您轻松应对多种ETL数据处理和业务探索场景。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券