1    问题源起 上游系统通过公司rpc框架调用我们系统接口超时(默认超时时间为100ms)数量从50次/分突然上涨到2000次/分,在发生变化时间段里我们的系统也没有做过代码变更,但上游系统的调用确发生了变化.由于处于主要链路上,sre同学找过来询问原因,所以开始了问题排查. 2    问题初步定位 排查rpc超时的基本思路是这样的: 1)        服务端处理确实超时 2)        服务端或者客户端由于某种原因卡住 a)         磁盘清理 b)        tr线程池

本文转载自公众号:涤生的博客,阅读时间大约需要11分钟.涤生的文章看起来跟破案一样,很精彩,很有启发. 前言 博客已经好久没有更新了,主要原因是 18 年下半年工作比较忙,另外也没有比较有意思的题材,所以迟迟没有更新.此篇是 18 年底的微信上的某同学提供的一个 Young GC 问题案例,找我帮忙解决.这个 GC 案例比较有意思,虽然过去有一段时间了,但是想想觉得还是有必要写出来,应该对大家很有帮助.排查问题有点像侦探断案,先分析各种可能性,再按照获得的一个个证据,去排除各种可能性.然后定位原

jstat命令使用 jstat是JDK自带的一个轻量级小工具,全称"Java Virtual Machine statistics monitoring tool",它位于java的bin目录下,主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控,包括了对Heap size和垃圾回收状况的监控. 命令格式 ➜ ~ jstat -help Usage: jstat -help|-options jstat -<option> [-t] [-h<

一.-XX:+PrintGCDetails 打印GC日志 参数配置:-Xms10M -Xmx10M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps  -Xloggc:F:\gc1.log -Xloggc:输出到文件 2020-01-03T14:13:18.866+0800: 0.224: [GC (Allocation Failure) [PSYoungGen: 2048K->496K(2560K)] 2048K

一.在JVM中什么是垃圾?如何判断一个对象是否可被回收?哪些对象可以作为GC Roots的根 垃圾就是在内存中已经不再被使用到的空间就是垃圾. 1.引用计数法: 内部使用一个计数器,当有对象被引用+1,没有就-1,但是没有办法解决循环引用的问题,JVM不采用此类回收法 2.枚举根节点可达性分析(GC Root) 它必须是一组活跃的引用 思路:通过一系列名为GC Roots的对象作为起始点,从这个被称为GC Root的对象开始向下进行搜索,如果一个对象达到GC Roots 没有任何的引用链相连时,

前序文章: JVM性能调优(1) -- JVM内存模型和类加载运行机制 JVM性能调优(2) -- 垃圾回收器和回收策略 JVM性能调优(3) -- 内存分配和垃圾回收调优 一.JDK工具 先来看看有哪些常用的工具可以辅助我们进行性能调优和问题排查,后面再通过一个具体的示例结合工具来分析调优. 1.JDK工具 JDK自带了很多性能监控工具,我们可以用这些工具来监测系统和排查内存性能问题. 2.利用 jps 找出进程 jps(Java Virtual Machine Process Status

线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍. 同时例如jstack.jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df.free.top 三连,然后依次jstack.jmap伺候,具体问题具体分析即可. CPU 一般来讲我们首先会排查cpu方面的问题.cpu异常往往还是比较好定位的.原因包括业务逻辑问题(死循环).频繁gc以及上下文切换过多.而最常见的往往是业务逻辑(或者框架逻辑)导致的,可以使

参考:https://fredal.xin/java-error-check?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍.同时例如jstack.jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df.free.top 三连,然后依次jstack.jmap伺候,具体问题具体分析

JVM小册(1)------jstat和Parallel GC日志 一. 背景 在生产环境中,有时候会遇到OOM的情况,抛开Arthas 等比较成熟的工具以外,我们可以使用java 提供的jatat和jps.jmap等工具来帮助我们排查问题和定位原因,本系列小册先简单记录一下实际使用方式,后续对JVM进行分析. 二. 场景举例 比如目前有一台服务器,部署了一个java服务,我们为它分配的堆内存如下: #最大堆内存4G,最小2G, 一般来说建议这2个参数设置成一样的,减少因为GC以后动态内存扩容对

在高并发下, Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大. 不管是 「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务超时,引发性能问题. 内容分成以下2个部分: 从一次YGC耗时过长的案例说起 YGC的相关知识点总结 01 从一次YGC耗时过长的案例说起 今年4月份,我们的广告服务在新版本上线后,收到了大量的服务超时告警,通过下面的监控图可以看到:超时量突然大面积增加,1分钟内甚至达到了上千次接口超时.下面

目标: Jmap.Jstack.Jinfo详解 JvisualVm调优工具实战 JVM内存或CPU飙高如何定位 JState命令预估JVM运行情况 系统频繁Full GC导致系统卡顿实战调优 内存泄漏到底是怎么回事? 一.前言 因为我的是mac电脑,所以运行程序都是在mac上,有时一些工具在mac上不是很好用.如果有不好用的情况,可以参考文章: 1. mac安装多版本jdk 2. 彻底解决Jmap在mac版本无法使用的问题 以上是我在mac上运行Jmap时遇到的问题,如果你也遇到了,可以查看.

Arthas线上 分析诊断调优工具 以前我们要排查线上问题,通常使用的是jdk自带的调优工具和命令.最常见的就是dump线上日志,然后下载到本地,导入到jvisualvm工具中.这样操作有诸多不变,现在阿里团队开发的Arhtas工具,拥有非常强大的功能,并且都是线上的刚需,尤其是情况紧急,不方便立刻发版,适合临时处理危急情况使用.下面分两部分来研究JVM性能调优工具: 1.JDK自带的性能调优工具 虽然有了Arthas,但也不要忘记JDK自带的性能调优工具,在某些场景下,他还是有很大作用的.而且

CPU 磁盘 内存 GC问题 网络 线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍. 同时例如jstack.jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df.free.top 三连,然后依次jstack.jmap伺候,具体问题具体分析即可. CPU 一般来讲我们首先会排查cpu方面的问题.cpu异常往往还是比较好定位的.原因包括业务逻辑问题(死循环).频繁gc以及上下文切换过多.而最常见的往往是业

一.前提 JVM性能调优牵扯到各方面的取舍与平衡,往往是牵一发而动全身,需要全盘考虑各方面的影响.在优化时候,切勿凭感觉或经验主义进行调整,而是需要通过系统运行的客观数据指标,不断找到最优解.同时,在进行性能调优前,您需要理解并掌握以下的相关基础理论知识: 1.JVM垃圾收集器和垃圾回收算法 2.JVM性能监控常用工具和命令 3.JVM运行时数据区域 4.能够读懂gc日志 5.内存分配与回收策略 二.JVM内存结构 从上图可以看出,整个JVM内存是由栈内存.堆内存和永久代构成. 年轻代(New

引言 本文记录一次线上 GC 问题的排查过程与思路,希望对各位读者有所帮助.过程中也走了一些弯路,现在有时间沉淀下来思考并总结出来分享给大家,希望对大家今后排查线上 GC 问题有帮助. 背景 服务新功能发版一周后下午,突然收到 CMS GC 告警,导致单台节点被拉出,随后集群内每个节点先后都发生了一次 CMS GC,拉出后的节点垃圾回收后接入流量恢复正常(事后排查发现被重启了). 告警信息如下(已脱敏): 多个节点几乎同时发生 GC 问题,且排查自然流量监控后发现并未有明显增高,基本可以确定是有

这十年来,在图像处理领域提出了很多新的图像分析和处理方法,包括是自动的以及一些需要有人工参与的,典型的比如stereo depth computations.image colorization.tone mapping of high dynamic range (HDR) images. graph cuts ,这些算法都有着比较好的效果,但都普遍存在一个问题:就是计算量特别大,很难满足用户的需求.而数字图像在尺寸大小上的增长速度这段时间也相当惊人.还有个问题就是有些算法需要解一个很大的稀疏

测试一 字段:ID,test,number 电脑配置:8g内存 同时写入超过5w条,就会卡死 错误提示 Fatal error: Allowed memory size of bytes exhausted (tried to allocate bytes) 测试二 字段:ID,test,number 电脑配置:8g内存 写入记录5w, 耗时:10s 读取5w,耗时 字段:ID,name,number 100w记录 SUM耗时只需要0.233s 100w记录 count(*)耗时只需要0.165

我发现开发项目用的redis 隔一两分钟就出现 耗时问题,长达五秒.一开始以为是 redis 服务器不稳定,但运维测试发现redis稳定的,在高并发下最大耗时也就只有100毫秒左右,怎么也不可能达到5秒. 排除redis服务器稳定性问题后,就只有可能网络抖动问题 和 客户端redis配置及代码问题了,监控了 redis 耗时后发现了诡异的地方,如下图~

SQL Server定时自动抓取耗时SQL并归档数据发邮件脚本分享 第一步建库和建表 USE [master] GO CREATE DATABASE [MonitorElapsedHighSQL] GO --建表 USE [MonitorElapsedHighSQL] GO --1.表[SQLCountStatisticsByDay] --抓取到的sql语句数量 CREATE TABLE [dbo].[SQLCountStatisticsByDay] ( id , ) PRIMARY KEY ,

前面两篇分别介绍了通过脚本和C代码读写/sys/class/gpio以控制GPIO.实际项目调试时经常还需要在Java代码里控制GPIO,其实现与C代码类似,唯一不同是Android权限.本文重点介绍Android6.0权限的配置并对在Java层控制GPIO的耗时做简单分析. 以高通平台为例,权限配置主要修改HLOS/device/qcom/sepolicy/common目录下的file.te.file_contexts和system_app.te三个文件. file.te修改如下, # GPI

图像处理中,有很多算法由于其内在的复杂性是天然的耗时大户,加之图像本身蕴涵的数据量比一般的对象就大,因此,针对这类算法,执行速度的提在很大程度上依赖于硬件的性能,现在流行的CPU都是至少2核的,稍微好点的4核,甚至8核,因此,如果能充分利用这些资源,必将能发挥机器的强大优势,为算法的执行效果提升一个档次. 在单核时代,多线程程序的主要目的是防止UI假死,而一般情况下此时多线程程序的性能会比单线程的慢,这种情况五六年前是比较普遍的,所有哪个时候用VB6写的图像程序可能比VC6的慢不了多少.可在多核