一般而言cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的,可以使用jstack来分析对应的堆栈情况。

使用jstack排查占用率问题

当使用jstack排查占用率问题时,可以按照以下步骤进行:

  1. 首先,使用top命令找到占用率较高的进程,并记录其PID。
  2. 接着,使用以下命令来查看该进程中占用CPU较高的线程:
top -H -p <pid>

该命令将显示进程中各个线程的CPU使用率,以及线程的ID(TID)。

3. 根据线程ID(TID)获取nid,可以使用以下命令:

printf '%x\n' <tid>

这将把TID转换为16进制格式的nid。

4. 然后,通过以下命令来查看该线程的堆栈信息:

jstack <pid> | grep 'nid' -C5 --color

该命令将显示包含nid的堆栈信息。注意,这里使用了grep命令来过滤输出结果,只显示包含nid的部分。-C5表示在匹配项前后各显示5行上下文信息,--color则用于在输出中添加颜色标记。

5. 除了逐个查看线程的堆栈信息外,还可以对整个jstack文件进行分析。可以使用以下命令来统计各个状态的线程数量:

cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c

该命令将输出各个线程状态的数量,例如RUNNABLE、BLOCKED、WAITING、TIMED_WAITING等。如果WAITING或TIMED_WAITING的数量较多,那么可能存在一些问题。

通过以上步骤,我们可以使用jstack来定位占用率较高的问题,并进一步分析问题原因。

频繁GC问题

通过使用jstat工具的-gc选项,我们可以观察GC的分代变化情况,以便确定GC是否过于频繁。具体来说,我们可以使用以下命令来观察进程的GC情况:

jstat -gc <pid> 1000

在上述命令中,<pid>是目标Java进程的PID,而1000表示采样间隔(以毫秒为单位)。通过这个命令,我们可以获取关于Survivor区、Eden区、老年代(Old Generation)、元数据区(Metaspace)的容量和使用量信息,以及关于Young GC和Full GC的耗时和次数以及总耗时信息。



具体来说,以下是一些关键指标的含义:

  • S0C/S1C和S0U/S1U:这两个指标分别表示Survivor 0区和Survivor 1区的容量和已使用的容量。如果这些值接近或达到其最大值,则可能需要进行GC。
  • EC/EU:这两个指标分别表示Eden区的当前容量和已使用的容量。如果这些值接近或达到其最大值,则可能需要进行GC。
  • OC/OU:这两个指标分别表示老年代的当前容量和已使用的容量。如果这些值接近或达到其最大值,则可能需要进行GC。
  • MC/MU:这两个指标分别表示元数据区的当前容量和已使用的容量。如果这些值接近或达到其最大值,则可能需要进行GC。
  • YGC/YGT:这两个指标分别表示Young GC的次数和所花费的总时间。如果这些值较高,则可能表明应用程序存在过多的短期对象引用,需要优化。
  • FGC/FGCT:这两个指标分别表示Full GC的次数和所花费的总时间。如果这些值较高,则可能表明应用程序存在过多的长期对象引用,需要优化。
  • GCT:这个指标表示应用程序进行GC的总时间。如果这个值较高,则可能表明应用程序需要进行优化以减少GC的开销。

通过观察这些指标,我们可以更好地了解Java进程的内存使用情况和垃圾回收情况。如果发现GC过于频繁或存在其他问题,我们可以进一步分析并采取相应的优化措施。

频繁上下文切换

上下文切换会消耗CPU的时间,并导致进程真正运行的时间缩短,从而成为系统性能下降的一个因素。过多的上下文切换可能会使得CPU花费过多的时间用于保存和恢复寄存器、内核栈以及虚拟内存等数据,从而影响系统的响应速度和吞吐量。

vmstat是一个非常有用的系统性能分析工具,它可以提供关于系统内存、CPU活动、分页和上下文切换等信息。

在使用vmstat查看上下文切换情况时,可以显示以下统计信息:

  1. "cs"(上下文切换):显示系统每秒上下文切换的次数。自愿上下文切换(voluntary context switches)和非自愿上下文切换(non voluntary context switches)都会被计算在内。
  2. "in"(中断):显示系统每秒中断的次数。这些中断可能来自硬件设备、网络或其他原因。
  3. "r"(运行或可运行):显示正在运行或等待CPU的进程数。这个统计信息可以提供关于系统负载的总体视图。
  4. "b"(阻塞):显示处于不可中断睡眠状态的进程数。这些进程通常是在等待某些资源(如I/O操作)可用。

需要注意的是,vmstat命令的具体选项和输出可能会因操作系统和版本而有所不同。在使用vmstat时,建议查阅相关文档或使用"man vmstat"命令来获取特定系统上vmstat的详细使用说明和输出解释。

vmstat是给出整个系统总体的上下文切换情况,要想查看每个进程的详细情况就需要使用pidstat,加上-w选项就可以查看进程上下文切换的情况 pidstat -w pid命令,cswch和nvcswch表示自愿及非自愿切换。

cswch(voluntary context switches):表示每秒自愿上下文切换的次数
nvcswch(non voluntary context switches):表示每秒非自愿上下文切换的次数
  1. 自愿上下文切换:进程无法获取所需的资源,导致的上下文切换,例如IO、内存等资源不足时,就会发生自愿上下文切换
  2. 非自愿上下文切换:进程由于时间片已到等时间,被系统强制调度,进而发生的上下文切换,例如大量的进程都在争抢CPU时,就容易发生非自愿上下文切换

系统上下文切换的次数为多少时是不正常的呢?

系统上下文切换的次数是否正常,取决于系统本身的CPU性能。一般来说,如果系统的上下文切换次数比较稳定,在数百到一万以内,都应该算是正常的。然而,当上下文切换次数超过一万次,或者切换次数出现数量级的增长时,就可能已经出现了性能问题。

具体遇到问题的时候,需要根据变化的上下文切换类型,再做具体分析。例如:自愿上下文切换变多了,说明进程都在等待资源,有可能发生了I/O等其他问题;非自愿上下文切换变多了,说明进程都在被强制调度,也就是都在争抢CPU,说明CPU的确成了瓶颈;中断次数变多了,说明CPU被中断处理程序占用,还需要通过查看/proc/interrupts文件来分析具体的中断类型。

服务器常见问题排查(一)——cpu占用高、上下文频繁切换、频繁GC的更多相关文章

  1. SQLSERVER排查CPU占用高的情况

    SQLSERVER排查CPU占用高的情况 今天中午,有朋友叫我帮他看一下数据库,操作系统是Windows2008R2 ,数据库是SQL2008R2 64位 64G内存,16核CPU 硬件配置还是比较高 ...

  2. Java中的CPU占用高和内存占用高的问题排查

    下面通过模拟实例分析排查Java应用程序CPU和内存占用过高的过程.如果是Java面试,这2个问题在面试过程中出现的概率很高,所以我打算在这里好好总结一下. 1.Java CPU过高的问题排查 举个例 ...

  3. centos7-java模拟cpu占用高及排查

    环境 centos7 1核2GB Java8 模拟cpu占用高 新建一个名为jvm-learn的springboot项目 模拟代码如下 import org.springframework.boot. ...

  4. Microsoft(C)注册服务器(32位)CPU占用高

    Microsoft(C)注册服务器(32位)CPU占用高 摘自:https://blog.csdn.net/jtsqrj/article/details/83034252 2018年10月12日 23 ...

  5. CENTOS7-JAVA模拟CPU占用高及排查( 转)

    环境 centos7 1核2GB Java8 模拟cpu占用高 新建一个名为jvm-learn的springboot项目 模拟代码如下 import org.springframework.boot. ...

  6. 一次生产环境CPU占用高的排查

    1. 项目背景 甲方是保密级别非常高的政府部门.所以我们全程拿不到任何测试数据,只能是自己模拟数据进行测试. 项目部署的时候,公司派了一人到甲方现场,在甲方客户全程监督下,进行部署,调试,导入数据等工 ...

  7. Mysql CPU占用高的问题解决方法小结

    通过以前对mysql的操作经验,先将mysql的配置问题排除了,查看msyql是否运行正常,通过查看mysql data目录里面的*.err文件(将扩展名改为.txt)记事本查看即可.如果过大不建议用 ...

  8. MongoDB优化之三:如何排查MongoDB CPU利用率高的问题

    遇到这个问题,99.9999% 的可能性是「用户使用上不合理导致」,本文主要介绍从应用的角度如何排查 MongoDB CPU 利用率高的问题. Step1: 分析数据库正在执行的请求 用户可以通过 M ...

  9. JVM 线上故障排查基本操作--CPU飙高

    JVM 线上故障排查基本操作 CPU 飚高 线上 CPU 飚高问题大家应该都遇到过,那么如何定位问题呢? 思路:首先找到 CPU 飚高的那个 Java 进程,因为你的服务器会有多个 JVM 进程.然后 ...

  10. C# Winform程序CPU占用高的原因和解决方法

    程序CPU占用高的可能原因: 1.存在死循环: 为什么死循环会导致CPU占用高呢?      虽然分时操作系统是采用时间片的机制对CPU的时间进行管理的,也就是说到了一定时间它会自动从一个进程切换到下 ...

随机推荐

  1. 检测到 #include 错误。请更新 includePath。已为此翻译单元 禁用波形曲线

    也有可能是VSCode抽风了 重启就好

  2. HCL实验6:静态路由

    拓扑图 步骤: 连线,路由器与路由器通过S端口连接 配置好PC 配置路由器端口IP 配置路由器的下一跳地址(静态路由) 详细步骤 连线情况可见拓扑图 配置好PC 端口IP R1 [R1]int g0/ ...

  3. 阿里云容蓓:DCDN 助力云原生时代的应用构建及最佳实践

    在数字化转型速度不断提升的今天,大带宽.低时延.高并发的场景不断涌现,内容分发网络(Content Delivery Network,CDN)应用需求还在不断攀升,打造更高质量的CDN服务将成为新时代 ...

  4. LeanCloud 国内域名解析问题,博客评论及阅读数显示失败

    近日,LeanCloud 国内域名解析存在问题,个人博客基于LeanCloud构建的评论及阅读数显示失败. 个人博客地址 关于 LeanCloud 国内域名解析问题的情况更新(6 月 21 日) 声明 ...

  5. Python 学习笔记:基础篇

    ! https://zhuanlan.zhihu.com/p/644232952 Python 学习笔记:基础篇 承接之前在<[[Python 学习路线图]]>一文中的规划,接下来,我将会 ...

  6. Word转换HTML(Java实用版)

    前言: 在业务中,如果需要在浏览器中预览Word文档,或者需要将Word文档转成HTML文件保存,那么本章内容,可以帮助到你. 实现这一功能,有多种实现方式,如:docx4j.poi.Free Spi ...

  7. Django2.2:UnicodeDecodeError: 'gbk' codec can't decode byte 0xa6 in position 9737: illegal multibyte sequence

    报错截图: 解决方案: 打开django/views下的debug.py文件,转到line331行: with Path(CURRENT_DIR, 'templates', 'technical_50 ...

  8. OpenAI API访问速度不佳?试试用Vercel来加速!

    前言 众所周知,使用openAI API在国内访问体验并不佳,经常遇到访问较慢或者访问失败的问题.本文着重讲讲怎么解决这个问题,让我们日常开发和使用能够更方便的体验到AI带来的便利 为了帮大家省钱,也 ...

  9. rest-apiV2.0.0升级为simplest-api开源框架生态之simplest-jpa发布

    什么是 simplest simplest 追求存粹简单和极致. 旨在为项目快速开发提供一系列的基础能力,方便用户根据项目需求快速进行功能拓展 不在去关心一些繁琐.重复工作,而是把重点聚焦到业务. 前 ...

  10. 交换分区swap的创建与管理

    前言 swap分区是linux系统中一块特殊的硬盘空间,当实际内存不够用的时候,系统会按照一定的算法将部分不用的数据放在swap分区中,从而为当前运行的程序腾出足够的内存空间.好处在于避免内存资源不足 ...