解析线上HBase集群CPU飙高的原因与解决方案

这篇具有很好参考价值的文章主要介绍了解析线上HBase集群CPU飙高的原因与解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

在日常的运维工作中,CPU负载高是一种常见的故障状况,它可能对系统的正常运行和性能产生不利影响。为了准确地定位具体的异常原因,掌握一些专业的工具和方法是至关重要的。本文将通过一个实际的案例,详细介绍如何排查在线上HBASE集群CPU飙高问题,并分享相关工具的使用技巧以及基本的排查思路。通过阅读本文,读者将能够更加全面地了解和应对CPU负载高的问题,提升运维工作的效率和准确性。

解析线上HBase集群CPU飙高的原因与解决方案

1.线上现象描述

业务侧反馈,客户调用hbase集群相关操作的接口出现超时现象。查看监控信息,对应hbase集群有CPU负载突增且持续飚高的告警。

cm的监控图表:分别是CPU、网络、磁盘、集群请求。

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

2.定位原因

一般出现上面cpu直接飙高的问题,最容易想到的排查方式就是到主机上查看单个主机cpu的状况,定位出单个主机CPU占比很高的进程;

主机高CPU的进程定位通常有以下几种方式

  • 使用top命令:top命令可以实时监视系统的进程和资源使用情况。在top命令的输出中,按下"Shift + P"键,可以按照CPU使用率对进程进行排序,最高的进程将位于列表的顶部。

  • 使用htop命令:htop是top命令的改进版,提供了更多的交互式功能。在htop命令的界面中,按下"F6"键,然后选择"PERCENT_CPU"选项,可以按照CPU使用率对进程进行排序。

  • 使用ps命令:ps命令可以列出当前运行的进程。使用命令"ps -eo pid,ppid,%cpu,%mem,cmd"可以显示进程的PID、父进程ID、CPU使用率、内存使用率和命令行。

  • 使用pidstat命令:pidstat命令可以提供有关进程的详细统计信息,包括CPU使用率。使用命令"pidstat -p <PID> -u"可以查看指定进程的CPU使用率。

  • 使用perf工具:perf是一个功能强大的性能分析工具,可以用于定位高CPU占用的进程。使用perf可以获取进程的堆栈跟踪信息和性能计数器数据,帮助分析进程的性能瓶颈。

上面用的最多一般是top命令,本文也是结合top来做的分析:

下面是主机top下的截图:

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

从上图中可以定位到cpu飙高是因为hbase用户的一个java进程导致,如果主机上用hbase用户启用了多个java进程,此时想定位具体的进程详细信息时,就需要借助于ps命令;

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

定位到具体的进程之后,我们只能看到进程级别的CPU使用情况,如果想具体的分析原因,还需要定位到进程中线程级别的cpu使用情况。此时就需要结合top的一些参数使用。

top -H -p <PID>  
// 这个指令可以展示出指定进程的线程的资源使用情况;

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

上面可以定位出具体的线程cpu使用情况,只能获取哪些线程占用较高的cpu,但是仅有一个线程id号,如果想知道具体线程的详细信息,就需要使用到java的堆栈分析工具jstack 。

jstack 介绍

jstack是Java开发工具包(JDK)中提供的一个命令行工具,用于生成Java虚拟机(JVM)中所有线程的堆栈跟踪信息。

使用jstack命令可以获取以下信息:

  1. 所有线程的堆栈跟踪:jstack命令会输出JVM中所有线程的堆栈跟踪信息,包括线程ID、状态、执行方法和行号等。这些信息可以用于分析线程的执行路径和可能的问题。

  2. 死锁检测:jstack命令可以检测并输出JVM中的死锁情况。它会显示死锁的线程以及导致死锁的资源。

tips:遇到java进程出现如死锁、死循环、长时间停顿等问题,都可以借助此工具来定位分析问题

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

提示:在执行上面指令的时候,需要切换到进程启动的用户下,否则会有报错。

等指令运行完成,会输出所有线程的堆栈跟踪信息到指定的文件中,文件的大致内容格式如下:

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

获取到内容还不可以根据线程的id直接来匹配线程的详细信息,这里需要将top 展示出来的线程id转换成16进制格式,转换的方式直接使用linux系统自带的格式输出工具 printf。

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

"printf "%x\n" 7888"命令将输出16进制整数30648的值,即1ed0。

最后就可以通过转换后的16进制的id值在上述文件中匹配到对应的线程信息;

hbase 能承受高qps的原因,集群架构/运维/监控/告警,Hbase剖析与Hbase集群运维,hbase,数据库,大数据

内容分析

  • "regionserver/10-xxx-xxx:16020-longCompactions-1694499929193" #451 daemon prio=5 os_prio=0 tid=0x00007fe4dc7a6800 nid=0x1ed0 runnable [0x00007fdc59236000]:线程名称是"regionserver/10-xxx-xxx:16020-longCompactions-1694499929193",线程ID(TID)为0x00007fe4dc7a6800,线程优先级为5,是守护线程(daemon),线程状态为runnable,线程在内存中的地址为0x00007fdc59236000。

  • java.lang.Thread.State: RUNNABLE:Java线程的状态为RUNNABLE(可运行)。

  • at org.apache.hadoop.hbase.CellComparatorImpl.compareQualifiers(CellComparatorImpl.java:169):此行显示了线程正在执行的方法,即org.apache.hadoop.hbase.CellComparatorImpl.compareQualifiers,位于CellComparatorImpl.java文件的第169行。

  • 其他的几行也是类似的,显示了线程在执行过程中经过的方法调用和对应的代码行号。

3.问题处理

通过以上方法的问题定位,最终知道导致集群cpu飙高的原因是Hbase集群在进行表的compaction导致的。

由此也知道hbase表的compaction操作确实是十分的损耗集群的性能的,但是这个又是Hbase集群的数据清理和优化的重要操作。所以需要集群的资源状态和结合业务的情况来合理的调起compaction。文章来源地址https://www.toymoban.com/news/detail-827201.html

到了这里,关于解析线上HBase集群CPU飙高的原因与解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【性能优化】CPU利用率飙高与内存飙高问题

    📫作者简介: 小明java问道之路 , 2022年度博客之星全国TOP3 ,专注于后端、中间件、计算机底层、架构设计演进与稳定性建设优化,文章内容兼具广度、深度、大厂技术方案,对待技术喜欢推理加验证,就职于知名金融公司后端高级工程师。          📫 热衷分享,喜欢原

    2024年02月05日
    浏览(57)
  • 3个命令定位CPU飙高

    top 指令找出消耗CPU最厉害的那个进程的pid top -H -p 进程pid 找出耗用CPU资源最多的线程pid printf ‘0x%xn’ 线程pid 将线程pid转换为16进制 结合jstack 找出哪个代码有问题 jstack 进程pid | grep 16进制的线程pid -A 多少行日志 jstack 进程pid | grep 16进制的线程pid -A 20

    2024年02月14日
    浏览(69)
  • docker服务CPU飙高排查

    什么是Docker服务CPU飙高? Docker是一个开源的容器化平台,它允许开发者将应用程序及其依赖项打包成一个独立的容器,以保证应用程序在不同的环境中都能够运行。然而,有时我们可能会遇到Docker服务CPU飙高的问题,即Docker服务占用了过多的CPU资源。 当Docker服务CPU飙高时,

    2024年02月04日
    浏览(41)
  • CPU 飙高问题排查和解决方法

    摘要 本文档记录了排查 CPU 飙高问题的处理过程和解决方法,从多个方面进行分析和排查。 问题简述 在一个生产环境中发现 CPU 飙高问题,但是无法确定问题的具体原因。 排查方法 使用 jstack 导出 JAVA 进程的线程栈信息,并分析线程栈信息,看能否定位到耗费 CPU 的线程。

    2024年02月07日
    浏览(52)
  • 【JVM】CPU飙高排查方案与思路

    1.使用 top命令 查看占用 cpu的情况 2.通过top命令查看后,可以查看是哪一个进程占用cpu较高,上图所示的进程为:40940 3.查看进程中的线程信息 4.可以根据进程 id 找到有问题的线程,进一步定位到问题代码的源码行号 因为根据进程ID 找到的线程id显示的是16进制,所以需要将查

    2024年02月13日
    浏览(37)
  • 数据库CPU飙高问题定位及解决

    在业务服务提供能力的时候,常常会遇到CPU飙高的问题,遇到这类问题,大多不是数据库自身问题,都是因为使用不当导致,这里记录下业务服务如何定位数据库CPU飙高问题并给出常见的解决方案。 在分析CPU使用率飙升根因前,先介绍下CPU使用率公式: 可见,CPU使用率与【

    2024年02月10日
    浏览(44)
  • Kibana 最常见的“启动报错”或“无法连接ES集群服务”的故障原因及解决方案汇总

    新手最常见的 Kibana 服务不可用的问题解答,此类问题如非有经验积累,可能耗费大量时间还不能解决,所以我特此整理了新手常见的 Kibana连不上集群或启动报错的问题及解决方案。 可能会有遗漏,如果你遇到的问题不在此列表,请私信提问,我会在此补充。 Kibana 服务正在

    2024年02月02日
    浏览(48)
  • mysql占用cpu超过100%怎么办?mysql占用cpu特别高的解决方法!

    前段时间我的一个网站经常打不开,通过检查发现服务器cpu占用超过100%;通过top命令发现是mysql占用cpu特别高导致的,于是优化了mysql语句,mysql升级到了mysql8最新版本等,但是并没有什么卵用。过几天有出现这种情况。甚至以为是服务器配置太低了,准备升级配置。 后面分

    2024年02月08日
    浏览(54)
  • Linux命令及CPU占用过高的定位分析思路

    不要使用vim打开大文件, vim会一次性读取所有内容到内存,容易造成宿主机内存溢出 。 打开文件前,可以使用 du -h命令查看文件大小 。一般,100MB以下为宜。 j 向下 30j 向下移动30行 k 向上 h 向左 l 向右 0 到行首 ^ 到行首第一个字符,如果前面有空格的话 $ 到行尾 gg 快速到

    2024年02月03日
    浏览(48)
  • 关于路由器CPU利用率过高的解决办法

    第一步, show process cpu 如显示IP input process is using a lot of CPU resources,检查以下情况: 一、Fast switching 在大流量的外出接口上是否被disabled.可以用 show interfaces switching 命令察看接口流量.然后在接口上重新 Re-enable fast switching .记住 fast switching是配置在output 接口. 二、Fast switching

    2024年02月06日
    浏览(54)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包