CPU 利用率高的排查方法

看看该机器的连接数是不是比其他机器多,监听的端口数:netstat -anlp | wc -l

Kafka-0.8的停止和启动

  • 启动: cd /usr/local/kafka-0.8.0-release/ && nohup ./bin/kafka-server-start.sh config/server.properties &
  • 停止: ps ax | grep -i 'kafka.Kafka' | grep -v grep | awk '{print $1}' | xargs kill -SIGTERM

kafka -0.10的启动和停止

  • 启动:sh /usr/local/kafka/kafka-release/bin/kafka-server-start.sh -daemon /usr/local/kafka/kafka-release/config/server.properties &
  • 停止: kill

1 问题描述

broker 连接Session超时,在zookeeper的临时节点删除,出发告警。查明超时的原因。

2 步骤

1.hpm查看byte-out,网络情况

2.hpm查看当时时间点的load

3.sar命令查看broker当时的网络负载:sar -n ALL -f /var/log/sa/sa08 | grep bond0 > ~/netinfo

3 tips

空闲的时候,查一下2016.7.22 4:27,broker:10.39.48.158的问题原因。

4 一个详细的问题

10.39.48.158机器出现了2次Session Time Out的问题。第二次现象:2016-7-24 12:36网络入口流量byte_in猛增到230M/s,load 达到70。它的其他情况是几M/s,load 稳定在1左右。由于它已经宕机过一次,所以该机器上没有作为任何topic的leader。这个猛增的流量是从何处来的呢?

  1. 排查作为topic partition的follower是否有BytesInPerSec这个metrics值
  • leader有,follower没有。方法:jmx获取同一个topic partition的leader和follower的BytesInPerSec值。

2.排查是否该机器作为follower在某时刻,由于leader所在的topic入口流量猛增,follower同步,导致入口流量猛增。

  • topic:weibomobile,在那时刻入口流量130M/s,48.158机器需要同步它的6个partition。还有别的小入口流量的topic,合计起来,增大了48.158机器的流量。

3.解决

  • 如果在出现类似的问题,将48.158机器的Session Time Out时间从6s,设置成30s,待观察。

5 机器48.158再次出现ZK节点丢失

1.现象

12:58获取到报警,即在12:57节点丢失后,在1min内没有连接上,因此触发报警。

观察该机器,

  • load_one 12:55:30-12:59:00 负载稳定在 75;
  • cpu_system 13:00:00-13:02:00 利用率在 12.8%
  • bytes_in 13:02:30 流量突增到 243M

2.分析

分析该机器上所有的46个topic所在的48.158的partition是否有激增的流量。该数据目前没有,需要收集。

在分析这46个topic的LogEndOffsetIncrease指标,发现12:55:00,所有topic的增加量猛增。

(???会不会是这个时间刻发生了GC)

原有的进程已经被kill重新启动了,查看了新启动的Kafka进程的GC,如下,是正常情况:YC 一次平均耗时38毫秒,FC 一次平均耗时325毫秒。

jstat -gcutil 7089
S0 S1 E O P YGC YGCT FGC FGCT GCT
5.18 0.00 68.29 14.54 60.00 308028 11991.504 1258 409.274 12400.778

很重要的一次GC信息 from 杰哥



kafka 宕机的时候,由于负载很高,流量很高,cms gc的remark耗时7s,导致kafka挂掉。(remark stop the word)

6 机器4.215、4.216、4.217 在ZK的节点丢失一次。

1.现象+分析

16/08/08 14:42:09 INFO eager.MonitorBrokerDown: -----broker down info:kafka broker had shutdown. Maybe this is a normal behavior.    last alive brokers:[19, 48151, 17, 18, 15, 48153, 48152, 16, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8].      current alive brokers:[19, 48151, 17, 18, 15, 48153, 48152, 16, 13, 48155, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8].      invalid broker ip info:{ "host":"10.39.4.215", "jmx_port":9999, "port":19092, "version":1 }

byte-out下降、byte-in下降、load下降,2.5.
02:30:01 PM bond0 119951.04 125071.66 114175.78 91512.58 0.00 0.00 11.26
02:40:01 PM bond0 118530.20 125037.93 110370.88 95596.69 0.00 0.00 11.13
02:50:01 PM bond0 85377.47 83437.07 90981.47 50017.23 0.00 0.00 10.94 16/08/08 16:35:33 INFO eager.MonitorBrokerDown: -----broker down info:kafka broker had shutdown. Maybe this is a normal behavior. last alive brokers:[19, 48151, 17, 18, 15, 48153, 48152, 16, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8]. current alive brokers:[19, 48151, 17, 18, 48153, 48152, 16, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8]. invalid broker ip info:{ "host":"10.39.4.216", "jmx_port":9999, "port":19092, "version":1 } byte-out:41-62M;byte-in:95-120M;load稳定在3左右。
04:10:01 PM bond0 132737.19 130567.37 138791.12 81211.07 0.00 0.00 11.25
04:20:01 PM bond0 131918.26 134324.10 129449.86 88444.40 0.00 0.00 11.22
04:30:01 PM bond0 97577.10 98807.90 93055.00 61815.56 0.00 0.00 11.32
04:40:01 PM bond0 98629.53 94743.99 108407.71 44847.14 0.00 0.00 11.34 16/08/08 17:08:07 INFO eager.MonitorBrokerDown: -----broker down info:kafka broker had shutdown. Maybe this is a normal behavior. last alive brokers:[19, 48151, 17, 18, 15, 48153, 48152, 16, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8]. current alive brokers:[19, 48151, 17, 18, 15, 48153, 48152, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8]. invalid broker ip info:{ "host":"10.39.4.217", "jmx_port":9999, "port":19092, "version":1 } byte-out:102-182M;byte-in:70-84M;load稳定,在1.6左右。
05:00:01 PM bond0 140487.48 174511.06 82636.05 184825.13 0.00 0.00 11.58
05:10:01 PM bond0 106820.66 125645.42 72597.47 118687.98 0.00 0.00 11.39
05:20:01 PM bond0 69833.26 64922.26 82521.11 24865.14 0.00 0.00 11.47

新出现10.39.4.210一天,zk节点丢失2次。

16/08/09 23:16:37 INFO eager.MonitorBrokerDown: -----broker down info:kafka broker had shutdown. Maybe this is a normal behavior.    last alive brokers:[19, 48151, 17, 18, 15, 48153, 16, 48152, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8].      current alive brokers:[19, 48151, 17, 18, 15, 48153, 16, 48152, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9].      invalid broker ip info:{ "host":"10.39.4.210", "jmx_port":9999, "port":19092, "version":1 }

分析:
byte-out:5M左右,byte-in:20M左右,load在5左右。Server日志无异常。
11:10:01 PM bond0 109463.54 123069.26 70532.96 107504.21 0.00 0.00 10.76
11:20:02 PM bond0 104557.60 111693.01 66477.78 80714.76 0.00 0.00 10.58
11:30:02 PM bond0 81705.83 73025.27 65993.75 7403.50 0.00 0.00 10.74 16/08/10 04:55:39 INFO eager.MonitorBrokerDown: -----broker down info:kafka broker had shutdown. Maybe this is a normal behavior. last alive brokers:[19, 48151, 17, 18, 15, 48153, 16, 48152, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9, 8]. current alive brokers:[19, 48151, 17, 18, 15, 48153, 16, 48152, 13, 48155, 14, 48154, 11, 48157, 12, 48156, 48158, 48159, 48160, 3, 2, 10, 1, 0, 7, 6, 5, 4, 9]. invalid broker ip info:{ "host":"10.39.4.210", "jmx_port":9999, "port":19092, "version":1 } byte-out:2M左右,byte-in:10M左右,load在11左右,
04:50:01 AM bond0 31866.19 28762.38 11614.37 3181.36 0.00 0.00 10.58
05:00:01 AM bond0 30127.26 27063.09 11909.66 3022.31 0.00 0.00 10.54
05:10:01 AM bond0 32618.83 29096.87 13870.89 3218.26 0.00 0.00 10.36

7. 机器4.220 kafka进程无法提供服务

1.现象

zk节点丢失。

2.分析

宕机的前几分钟load值从2升到83.

8. 机器4.210 近5天的时间,平均每天出现1次 zookeeper.session.timeout

排查该机器,每次断连的时候load_one的值突然变高,byte_in byte_out cpu 指标正常。

zookeeper连接默认的超时时间是 6000ms,见代码kafka/utils/ZkUtils.scala:743 ("zookeeper.session.timeout.ms", 6000)

解决:

  • 提高超时时间,zookeeper.session.timeout.ms=45000
  • bin/kafka-server-start.sh添加GC日志:export KAFKA_OPTS="-Xms4G -Xmx8G -Xmn3G -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 -server -Dlog4j.configuration=file:$base_dir/config/log4j.properties -Xloggc:/data0/kafka/log/gc.log -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime"

Kafka 0.8 宕机问题排查步骤的更多相关文章

  1. java调用jni oci接口宕机原因排查

    调用最简单的JNI没有出错,但是涉及到OCI时就会异常退出,分析后基本确定是OCI 11g中的signal所致,参考ora-24550 signo=6 signo=11解决. 但是这个相同的so库直接 ...

  2. 【JVM】linux上tomcat中部署的web服务,时好时坏,莫名其妙宕机,报错:There is insufficient memory for the Java Runtime Environment to continue.

    =========================================================================================== 环境: linu ...

  3. Oracle-11g-R2(11.2.0.3.x)RAC Oracle Grid & Database 零宕机方式回滚 PSU(自动模式)

    回滚环境: 1.源库版本: Grid Infrastructure:11.2.0.3.15 Database:11.2.0.3.15 2.目标库版本: Grid Infrastructure:11.2 ...

  4. Oracle-11g-R2(11.2.0.3.x)RAC Oracle Grid & Database 零宕机方式升级 PSU(自动模式)

    升级环境: 1.源库版本: Grid Infrastructure:11.2.0.3.13 Database:11.2.0.3.13 2.目标库版本: Grid Infrastructure:11.2 ...

  5. Kafka管理与监控——broker宕机后无法消费问题

    背景 因磁盘满了,导致kafka所有的服务器全部宕机了,然后重启kafka集群,服务是启动成功了,但有一些报错: broker1: broker2: broker3:一直在刷以下错误信息 虽然报了这些 ...

  6. 假如Kafka集群中一个broker宕机无法恢复,应该如何处理?

    假如Kafka集群中一个broker宕机无法恢复, 应该如何处理? 今天面试时遇到这个问题, 网上资料说添加新的broker, 是不会自动同步旧数据的. 笨办法 环境介绍 三个broker的集群, z ...

  7. 记一次Kafka服务器宕机的真实经历!!

    大家好,我是冰河~~ 估计节前前祭拜服务器不灵了,年后服务器总是或多或少的出现点问题.不知是人的问题,还是风水问题.昨天下班时,跟运维小伙伴交代了好几遍:如果使用Docker安装Kafka集群的话,也 ...

  8. 服务器宕机了,Kafka 消息会丢失吗?

    大家好,我是树哥. 消息队列可谓是高并发下的必备中间件了,而 Kafka 作为其中的佼佼者,经常被我们使用到各种各样的场景下.随着 Kafka 而来得,还有三个问题:消息丢失.消息重复.消息顺序.今天 ...

  9. quartz2.3.0(十三)数据库持久化定时器job任务和trigger触发器,在多个调度器实例情况下,由其它调度器实例恢复执行调度器宕机的job任务

    一.初始化数据库11张quartz表:qrtz_*   先从官网下载好quartz2.3.0包:http://www.quartz-scheduler.org/downloads/ 解压后进入目录:q ...

随机推荐

  1. 部署AlwaysOn第三步:集群资源组的健康检测和故障转移

    资源组是由一个或多个资源组成的组,WSFC的故障转移是以资源组为单位的,资源组中的资源是相互依赖的.一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的.在任何时刻,每个 ...

  2. okhttp3.4.1+retrofit2.1.0实现离线缓存

    关于Retrofit+OkHttp的强大这里就不多说了,还没了解的同学可以自行去百度.这篇文章主要讲如何利用Retrofit+OkHttp来实现一个较为简单的缓存策略:即有网环境下我们请求数据时,如果 ...

  3. .Net Core 分布式微服务框架介绍 - Jimu

    系列文章 .Net Core 分布式微服务框架介绍 - Jimu .Net Core 分布式微服务框架 - Jimu 添加 Swagger 支持 一.前言 近些年一直浸淫在 .Net 平台做企业应用开 ...

  4. Js_获取当前日期时间

    一.获取当前时间 new Date()方法---------得到结果是当前电脑时间如2011-11-6,10:07 二.获取有个固定的时间方法---------var endtime=new Date ...

  5. unity物理检测的几种方式

    (由于本人大多做2d游戏,因此以下以2d为主介绍,但是具体和3d相差不大) 在unity中有很多不同的物理检测方式,但是大致可以分为以下几种: 1.Physics2d检测系列 Physics2d.Li ...

  6. 毕业回馈-89c52之最小系统

    今天分享一个51单片机最小系统的电路板设计(原理图+PCB) 技术手册上面对于51单片机最小系统作如下要求: 下载电路主要有以下几种: 采用RS-232转换器下载:(R1OUT-P3.0;T1IN-P ...

  7. 微软职位内部推荐-Senior NLP Scientist

    微软近期Open的职位: Job Title: Senior NLP Scientist Location: Suzhou, China Suzhou, one of the most vibrant ...

  8. PAT甲题题解-1111. Online Map (30)-PAT甲级真题(模板题,两次Dijkstra,同时记下最短路径)

    题意:给了图,以及s和t,让你求s到t花费的最短路程.最短时间,以及输出对应的路径.   对于最短路程,如果路程一样,输出时间最少的. 对于最短时间,如果时间一样,输出节点数最少的.   如果最短路程 ...

  9. JAVA面对对象(二)——继承、方法的覆写

    1.继承就是基于已存在的类构造一个新类,继承已存在的类就能复用类的方法和属性,并且能够添加新的方法和属性.也就是子类和父类 2.一个父类可以拥有多个子类,一个子类只允许有一个父类 3.用extends ...

  10. final版本发布评价II

    其实我对技术上的问题了解不多,所以有些评语可能说的不对或者压根就没啥用.可直接忽略.请见谅. 1新蜂的俄罗斯方块,UI设计虽然给出了背景和颜色,但是感觉色彩对比也不好,模块之间也不协调.没有更多的说服 ...