问题背景 最近有同事说平台的某个服务出现超时异常，让我帮忙看下原因。我进入平台后触发了该服务，并没有发现超时异常，那可能是在特定操作场景下会出现或者是一个非必现问题。 既然已知道异常服务，那可以从这里入手进行分析，又与同事沟通一番，确定了与该服务相关的一些后台模块，接下来重点排查这些模块。 下面是出现问题的参考日志，关键点已包含其中，因为原日志不方便展示。 排查方法 日志中出现了sync. 问题本质 上面问题的根因是死锁导致的，死锁也是计算机中常见出现的问题。 往往改动代码引发的死锁问题比较容易出现，像本文中出现的问题就是代码改动导致的，添加功能需求的时候关注点集中在了业务逻辑上，容易忽视锁的问题。
排查Maven问题 mvn dependency:tree 三大技巧 第一板斧:找到传递依赖的鬼出在哪里？ （这一步非常重要哦，经常项目组pom.xml是相同的，但是就是有些人可以运行，有些人不能运行，俗称人品问题，其实都是IDE的缓存造成的了 idea清除缓存,为了提高效率不建议采用reimport重新起开启项目的方式
个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程，多款云服务器20元起。
jmap -histo pid | sort -n -r -k 2 | head -10
当出现异常以后，可以从以下几个原因入手排查。 API或数据结构使用不合理 慢查询。命令slowlog get [n]。 1）使用了复杂读为O(n)的命令导致，如hgetall等。 CPU饱和的问题。 内存交换 网络问题
一、前言 问题排查过程，源码部分均由我的开发同事排查和记录；在征得其同意后，由我发表在此。 二、问题 某天接到客户反馈，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 更新一次) 的时间，发现时间点刚好吻合，验证猜想。
日常问题排查-调用超时 前言 日常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左右。 另外， 对于一个偶发性的问题，我们应该通过监控等手段去寻找规律，这样就很容易找到突破点。
真实生产环境&预发的排查问题大杀器。 部分功能和btrace重合)：sc -df xxx：输出当前类的详情,包括源码位置和classloader结构；trace class method: 打印出当前方法调用的耗时情况，细分到每个方法, 对排查方法性能时很有帮助 更多请参考：官网 【6】JProfiler：之前判断许多问题要通过JProfiler，但是现在Greys和btrace基本都能搞定了。 再加上出问题的基本上都是生产环境(网络隔离)，所以基本不怎么使用了，但是还是要标记一下。
反过来，如果是服务器有问题，就返回5xx状态码。 4xx和5xx的区别 但问题就来了。 服务端都有问题了，搞严重点，服务器可能直接就崩溃了，那它还怎么给你返回状态码？ 这种情况几乎都是程序有代码逻辑问题，崩溃一般也会留下代码堆栈，可以根据堆栈报错去排查问题，修复之后就好了。比如下面这张图是golang的报错堆栈信息，其他语言的也类似。 实例已经销毁但配置没删IP 要排查这种问题也不难。 这个时候，你可以看下nginx侧是否有打印相关的日志，看下转发的IP端口是否符合预期。 如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。 如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。 ---- 最后 最近原创更文的阅读量稳步下跌，思前想后，夜里辗转反侧。 我有个不成熟的请求。
1.8 网络问题排查 在NAT模式下变成为桥接模式（右下角，网络适配器） 桥接模式下的方框，不用去选择，打钩。只需要点桥接模式就行 ? 先dhlicent -r释放IP地址 ?
问题 近期在开发过程中，突然出现混淆后程序出现运行时异常，编译是正常的，不混淆也是正常的， 错误信息如下提示 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掉了。
线上问题排查总结 Cpu飙高可能的原因 CAS自旋 没有控制自旋次数；乐观锁 死循环----cpu飙高的问题；控制循环次数 云服务器redis被注入挖矿程序；端口像公网暴露；Redis端口不要被外网访问 } },"晓果冻").start(); } } 指定线程名称 创建新的线程的时候最好指定它的名称不然默认的都是Thread-0、Thread-1这样的，指定名称，在排查问题时也方便在直接在项目 中搜索是哪段代码出了问题。 Linux环境下排查cpu飙高的问题 先模拟一种死锁的情况，让cpu飙高 /** * @author 晓果冻 * @version 1.0 * @date 2021/6/23 7:45 */ public 进程号改变是因为我又重启了程序 通过打印出的信息可以在代码中搜索晓果冻线程名来查询到底是哪段代码出了问题
出现该问题的原因有： 目标服务器防火墙配置更改，已关闭目标端口。 生产者（接口提供方）服务挂掉。 排查思路： 检查目标服务器防火墙配置，开启目标端口，重启防火墙 检查目标服务器服务状态 解决过程： 查看服务器调用者日志，当出现接口拒绝连接时，可参考以下方案： 使用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之前又要...
获取到curl后可以增加下面几个参数排查问题 -o /dev/null 不输出 -s 静默模式 -w 指定参数 curl 'https://jd.sopans.com/kefu/messages_page
排查思路 ---- 【1】定位高负载进程 pid：登录进服务器使用 top 或 top -c命令[ps -ef | grep xxx 命令]查看当前 CPU消耗过高的进程，从而得到进程id。
帮忙一起定位原因，最后定位到的问题说起来真的是很小的细节问题，但是就是这些小细节导致了服务不稳定，真是细节决定成败。这里尝试着来分享下，希望对大家有所帮助。 问题 1：占着茅坑不拉屎 遇到问题首先要看的还是服务器错误日志。 ，后来仔细读了 node-mysql 的文档及这个 issue，终于发现了我们的写法是有问题的。 问题 2：一条 UPDATE 引发的血案 我们再次查看了错误日志，发现了另一个异常报错：Error: ER_LOCK_WAIT_TIMEOUT: Lock wait timeout exceeded; 问题产生的原因可以这样来描述了：我们在执行 UPDATE 语句时，MySQL 会将其当成一个事务，对表的行进行锁定，这时又有其他连接进来要 UPDATE 同样的表或者 SELECT 这张表时就必须等待锁资源
线上问题排查神器 Arthas 之前介绍过 BTrace，线上问题排查神器 BTrace 的使用，也说它是线上问题排查神器。都是神器，但今天这个也很厉害，是不是更厉害不好说，但是使用起来非常简单。 如果你用 BTrace 的话，需要事先写好探测脚本，然后上传到需要排查问题的服务器，然后执行命令。比方说获取某个方法的参数、返回值、异常等。 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ 正式交互开始，就到了大展拳脚的时候了，线上出现的问题基本上都可以找到合适的命令。 下面简单的介绍几个，就是为了演示一下使用方式。 另外，无论是 Arthas 还是 BTrace ，都是用来排查单机服务问题的，也就是应用内部的代码、性能问题，如果要排查不同服务之间的调用问题，那就是另一个维度上的事儿了。就需要 APM 的帮助了。
云数据仓库Doris(cdwdoris)为您提供基于 MPP（大规模并行处理）架构的云端Doris托管服务，拥有开箱即用，弹性易扩展等特性。云数据仓库 Doris支持标准SQL语言，兼容MySQL协议，支持对PB级的海量数据进行高并发查询，和亚秒级的快速分析，帮助您轻松应对多种ETL数据处理和业务探索场景。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
云数据库 SQL Server
网站备案
文件存储
SSL 证书
