问题背景 最近有同事说平台的某个服务出现超时异常，让我帮忙看下原因。我进入平台后触发了该服务，并没有发现超时异常，那可能是在特定操作场景下会出现或者是一个非必现问题。...既然已知道异常服务，那可以从这里入手进行分析，又与同事沟通一番，确定了与该服务相关的一些后台模块，接下来重点排查这些模块。...下面是出现问题的参考日志，关键点已包含其中，因为原日志不方便展示。 排查方法 日志中出现了sync....问题本质 上面问题的根因是死锁导致的，死锁也是计算机中常见出现的问题。...往往改动代码引发的死锁问题比较容易出现，像本文中出现的问题就是代码改动导致的，添加功能需求的时候关注点集中在了业务逻辑上，容易忽视锁的问题。
排查Maven问题 mvn dependency:tree 三大技巧 第一板斧:找到传递依赖的鬼出在哪里？...（这一步非常重要哦，经常项目组pom.xml是相同的，但是就是有些人可以运行，有些人不能运行，俗称人品问题，其实都是IDE的缓存造成的了 idea清除缓存,为了提高效率不建议采用reimport重新起开启项目的方式
当出现异常以后，可以从以下几个原因入手排查。 API或数据结构使用不合理 慢查询。命令slowlog get [n]。 1）使用了复杂读为O(n)的命令导致，如hgetall等。...CPU饱和的问题。...内存交换 网络问题
1 查看当前系统的cpu，内存占用情况 [root@localhost ~]# top 2 平均加载时间 [root@localhost ~]# uptime...
jmap -histo pid | sort -n -r -k 2 | head -10
经过昨天晚上的调试，发现了一个主要问题：使用圆网格标定板标定时，不能使用cornerSubPix()函数，否则寻找角点时，会导致图一的情况(裁剪为30万像素)。就找到能参考的程序，推进还是很快的。...下次把有问题的数据列下。 上面数据均未使用图片校准。 目前这个相机标定程序比较OK，至此棋盘格和圆网格两种标定板。有需要的同志可在公众号后台留言“改进的相机标定程序”。
日常问题排查-调用超时 前言 日常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左右。...另外， 对于一个偶发性的问题，我们应该通过监控等手段去寻找规律，这样就很容易找到突破点。
一、前言 问题排查过程，源码部分均由我的开发同事排查和记录；在征得其同意后，由我发表在此。...二、问题 某天接到客户反馈，pod的事件中出现大量的 warning event: Readiness probe failed: OCI runtime exec failed: exec failed...三、环境 特别说明：客户在负责运行业务的k8s节点上坚持开启了cpu-manager 组件 版本 k8s 1.14.x 四、排查 1、接到客户反馈后，检查该pod所在节点的kubelet日志，如下...经过排查，发现 runc exec 在运行期间会读取 container 的 state.json，并使用 json decode 时出现异常。 ?...此时排查 runc EOF 和 kubelet cpu-manager update container(默认每 10s 更新一次) 的时间，发现时间点刚好吻合，验证猜想。
1、top 查看占用资源信息以及pid top 2、查看pid下绑定线程 top -Hp pid1(进程id) 3、拿到需要查询的线程pid,转换成16进制 p...
2.重启kubelet变更宿主状态 kubelet重启后宿主状态从Ready变为NotReady，这个问题相较docker hang死而言，没有那么复杂，所以我们先排查这个问题。...以往针对docker 1.13.1版本的排查都发现了一些线索，但是并没有定位到根因，最终绝大多数也是通过重启docker解决。...因此单纯依赖协程调用链路定位问题这条路被堵死了。 截至目前，我们已经收集了部分关键信息，同时也将问题排查范围更进一步地缩小在containerd-shim与runc之间。...接下来我们换一种思路继续排查。 3.2 进程排查 当组件的运行状态无法继续获取时，我们转换一下思维，获取容器的运行状态，也即异常容器此时的进程状态。...后续 docker hang死的原因远非这一种，本次排查的结果也并非适用于所有场景。希望各位看官能够根据自己的现场排查问题。
1.8 网络问题排查 在NAT模式下变成为桥接模式（右下角，网络适配器） 桥接模式下的方框，不用去选择，打钩。
真实生产环境&预发的排查问题大杀器。...部分功能和btrace重合)：sc -df xxx：输出当前类的详情,包括源码位置和classloader结构；trace class method: 打印出当前方法调用的耗时情况，细分到每个方法, 对排查方法性能时很有帮助...更多请参考：官网 【6】JProfiler：之前判断许多问题要通过JProfiler，但是现在Greys和btrace基本都能搞定了。...再加上出问题的基本上都是生产环境(网络隔离)，所以基本不怎么使用了，但是还是要标记一下。
反过来，如果是服务器有问题，就返回5xx状态码。 4xx和5xx的区别 但问题就来了。 服务端都有问题了，搞严重点，服务器可能直接就崩溃了，那它还怎么给你返回状态码？...这种情况几乎都是程序有代码逻辑问题，崩溃一般也会留下代码堆栈，可以根据堆栈报错去排查问题，修复之后就好了。比如下面这张图是golang的报错堆栈信息，其他语言的也类似。...实例已经销毁但配置没删IP 要排查这种问题也不难。 这个时候，你可以看下nginx侧是否有打印相关的日志，看下转发的IP端口是否符合预期。...如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。...如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。 ---- 最后 最近原创更文的阅读量稳步下跌，思前想后，夜里辗转反侧。 我有个不成熟的请求。
线上问题排查总结 Cpu飙高可能的原因 CAS自旋 没有控制自旋次数；乐观锁 死循环----cpu飙高的问题；控制循环次数 云服务器redis被注入挖矿程序；端口像公网暴露；Redis端口不要被外网访问...} },"晓果冻").start(); } } 指定线程名称 创建新的线程的时候最好指定它的名称不然默认的都是Thread-0、Thread-1这样的，指定名称，在排查问题时也方便在直接在项目...中搜索是哪段代码出了问题。...Linux环境下排查cpu飙高的问题 先模拟一种死锁的情况，让cpu飙高 /** * @author 晓果冻 * @version 1.0 * @date 2021/6/23 7:45 */ public...进程号改变是因为我又重启了程序 通过打印出的信息可以在代码中搜索晓果冻线程名来查询到底是哪段代码出了问题
若用户反馈线上服务请求无响应，可以按照以下步骤进行排查。 一、确认服务器内存使用情况 执行free命令，看看服务器内存是否正常。...7919 2106384 [B 7: 17131 1934896 java.lang.Class 如果这里看到有自己写的类对象，那可能就可以找到问题了...七、分析内存溢出问题 确定了是哪一个节点有问题，那么先把节点的流量切走。 如果第六步没分析出来是什么导致内存溢出，可以按如下步骤排查。 1....勾上了会保留不可达对象； 点击 file ---> open heap dump，选择刚才的dump文件，等待几分钟，mat工具会生成一个默认的报告； 默认报告里会列出problems，点击details就可以看到问题详情...，一般会列出有问题的对象； 选择有问题的对象，右键Merge Shortest Paths to GC Roots ---> exclude weak references； 然后再Java Basics
问题 近期在开发过程中，突然出现混淆后程序出现运行时异常，编译是正常的，不混淆也是正常的， 错误信息如下提示 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掉了。
出现该问题的原因有： 目标服务器防火墙配置更改，已关闭目标端口。 生产者（接口提供方）服务挂掉。...排查思路： 检查目标服务器防火墙配置，开启目标端口，重启防火墙 检查目标服务器服务状态 解决过程： 查看服务器调用者日志，当出现接口拒绝连接时，可参考以下方案： 使用ping IP命令查看目标服务器是否宕机
引言 上一篇文章中，我们看到了如何通过 wireshark 排查 TCP 重复 ACK 特别是由此引发的快速重发问题： 实战网络问题排查（五） -- 利用 wireshark 排查 TCP 快速重传问题...本文，我们就来利用 wireshark 来排查和定位 TCP 滑动窗口协议相关的问题。 2....这一情况下，无需进行处理，只需检查导致先前零窗口问题的原因。 TCP接收方频繁更改窗口大小。该情况下检查接收方被干扰的原因。可能是应用问题、内存问题、或者终端设备上的其他问题。...问题排查 如下图所示，是一个典型的空窗口问题的例子： 报文 183816 是 192.168.2.138 在 192.168.1.58 窗口占满之前的最后一条数据，因此被标记为 TCP WindowFull...除了检查内存分配以外，很有可能问题出在接收方处理能力不足，可以结合实际业务进一步进行排查。
Java发生死锁的根本原因是：在申请锁时发生了交叉闭环申请。即线程在获得了锁A并且没有释放的情况下去申请锁B，这时，另一个线程已经获得了锁B，在释放锁B之前又要...
'rocketMQTemplate' in 'RocketMQAutoConfiguration' not loaded because @ConditionalOnBean (types: org.apache.rocketmq.client.producer.DefaultMQProducer...; SearchStrategy: all) did not find any beans of type org.apache.rocketmq.client.producer.DefaultMQProducer...排查过程 启动的错误日志 2019-04-02 15:21:33.689 WARN 17516 --- [ main] s.c.a.AnnotationConfigApplicationContext...; SearchStrategy: all) did not find any beans of type org.apache.rocketmq.client.producer.DefaultMQProducer...问题原因 从上图中可以看到RocketMQAutoConfiguration中的mqProducer方法会根据配置参数来创建DefaultMQProducer，其中有两个必要的参数 spring.rocketmq.nameServer
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
