分类 Troubleshooting 相关 下的文章

监控指标的常见异常规则

我们收集各种层级的数据, 包括: 硬件层, hypervisor层, VM OS 层, JVM 层, 应用框架层, 应用层 或者基于 Docker 的 Node 数据, Pod 数据, Container 数据. 收集这么多数据大多数是为了出错时做分析, 不出错时做优化用. 把数据都转为时序数据后, 就可以对它们做异常检测和提前预知.
常见的异常检测是基于时间周期的, 比如每周的数据基本模式都是一样, 每天的数据模式也大致相同, 对比去年或前年的数据基本也可以用. 影响这些异常检测效果的一般有下面几种情况:

  1. 有些国家的冬令时和夏令时之间的转换;
  2. 有较大影响力的体育,政治事件, 比如美国超级碗会影响在线销售订单, 英国王室婴儿出生新闻会影响英国在线销售订单;
  3. 某些时间点的较大规模促销, 抢购会影响异常检测;
  4. 过年, 过节会影响, 这里有很大程度是因为无法发货, 或者发货也到不了导致的不购买;

- 阅读剩余部分 -

如何快速确认由具体某个类引起的JVM内存泄漏

在流量大致稳定的情况下, JVM 运行一段时间之后, 它的内存使用会趋于稳定, 我们通常认为这个时候做完一次 Full GC 之后的使用内存为稳定使用内存, 一般我们对 JVM 堆(heap) 大小的设置通常对比这个值做参考, 设置年轻代, 老年代的值. 当发生内存泄漏的时候, FuLL GC 之后的内存使用量表现为逐渐增大, 直到内存全部耗尽, 频繁的发生 full GC. 对于内存泄漏的问题, 我们一般捕获 heap dump, 然后分析, 当一个或一类对象实例所直接或间接占用的内存比例非常高的时候, 或者占用巨大的时候, 我们就会怀疑该类或对象. 那么有没有在不做 heap dump 的情况下, 快速定位某个对象是不是发生内存泄漏的方法呢?

- 阅读剩余部分 -

解决 JVM AttachNotSupportedException 的问题

对于 JVM GC overhead 的问题, 通常要在 overhead 很高的时候做 heap dump, 这样捕获的 dump 文件才更有意义. 可是在 GC overhead 很高的时候, 它消耗的 CPU 也很高, 通常把机器的 CPU 全占满. 这个时候尝试去使用 jcmd, jmap 去做 heap dump, 很高的概率会得到这个异常:

com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
    at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
    at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
    at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213)
    at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:140)
    at sun.tools.jcmd.JCmd.main(JCmd.java:129)

那么如何解决这个问题呢?

- 阅读剩余部分 -

如何获取 Java 应用 每个线程的 CPU usage

很多时候, 我们看到 Java 应用程序的 CPU 使用率很高, 或者是 GC 导致的, 或者是死循环导致的, 或者是执行某些特耗 CPU 的操作, 比如使用正则表达式匹配. 那么如何找这个使用率特别高的线程呢?


如何找出CPU 使用率最高的线程?

在 Linux 操作系统下, 使用 top -i 命令很容易找到CPU 使用率最高的进程, 如果使用 top -i -H 就很容易找到这个线程.

找到线程后, 如何查看它在忙什么呢?

使用 Linux 系统自带的 strace, ftrae, ltrace 等, 可以查看 OS 级别的系统调用, 函数, 库等调用, 可是无法查看用户空间的更多信息.

如何找出那些方法在消耗 CPU

通常有 2 种方法.

  1. 第一种是你大概知道那个方法耗时, 它可能是比较靠外层的方法, 你可以给他手工在方法开始和结束加一些代码, 然后计算时间差, 通过某些方式把时间差展现给你. 某些工具提供了一些面向方面(面向切面 Aspect Oriented Programing)的接口, 可以通过在线 unload 某些 class, 然后重新 load 加入新的切面的 class 来计算时间差, 比如 阿里开源的 Arthas;
  2. 通过 Sampling 的方式, 这种方法通过不断的对线程 stack 做 snapshot 然后画出火焰图. 通过火焰图, 很容易观察出那里占用了大量的 CPU 时间. 不过这里有个权衡, 多久做一个线程 stack 的 snapshot, 如果做的太多, 那么会影响CPU 的占用实际情况, 如果做的太少, 可能错过了最耗 CPU 的时间点, 或者每次正好错过这个点.

一个 Java 自带比较折中的方法.

在 Java 里, 我们可以通过程序的方式列出当前应用里面的所有正在运行的 Java 线程, 同时通过 MBean API 可以知道任何一个线程在开始之后占用的 CPU 时间. 如果我们在某个时间间隔的开始记录所有线程已经使用的时间, 在间隔的结尾再次记录, 那么就可以知道任何线程在这段时间内使用 CPU 的占用情况. 在这个间隔中间终止的线程, 不能给出正确的结果. 幸好大部分 Java 应用程序大部分使用线程池. 同时在间隔结尾处, 可以记录下线程栈的, 能大概给出一些信息. 如果一个线程长时间使用 CPU 很高, 可以做多次, 然后大概看出那部分代码比较耗 CPU.

如何具体实现

  1. 获得 ThreadMXBean
    ManagementFactory.getThreadMXBean();
  2. 获得线程 和 其它相关信息 ThreadMXBean
    首先通过 isThreadCpuTimeSupported() 方法获得是不是支持;
    可以获得死锁线程 findDeadlockedThreads()
    可以获得所有线程 ID: getAllThreadIds()
    可以获得一个线程已经使用的 CPU 时间: getThreadCpuTime(threadId)
    可以获得一个线程 Blocked 和 Waited time:
    ThreadInfo 的getBlockedTime() 和 getBlockedTime()
    ThreadInfo 的getWaitedTime() 和 getWaitedCount()
    可以通过 ThreadInfo 获得 stack -> getStackTrace()
  3. 其它要注意的地方
    ..1. 有几个 CPU -> Runtime.getRuntime().availableProcessors();
    ..2. 获得时间是 Nano time;
    ..3. 可以对使用率做百分比, 可以排序, 可以只看 Blocked 线程等.