性能文章>一次Zookeeper bug排查之旅 #论程序员,你曾遇到关于性能的那些事#>

一次Zookeeper bug排查之旅 #论程序员,你曾遇到关于性能的那些事#原创

1年前
561246

起因

某一天突然有同事说zk client连不上server,考虑到最近业务代码没有变更,怀疑是运维同学做了什么操作导致,急忙联系运维同学,确实最近做了变更。为了避免扩大影响范围,先让运维同学回滚了变更,回滚后可以正常访问了。

复现问题

询问运维同学后,得到变更流程:由于zk集群有一台服务器存在性能隐患,需要变更到新的一个实例。于是运维先将新机器加入zk集群,修改旧服务器上配置逐个重启,重启后新zk的角色是leader,此时zk状态正常,运维同学也就认为变更完成。
结果意想不到的是使用mntr命令查看,所有的机器状态都是正常,但是zk client无法访问,一访问就卡住,问题可以在测试环境稳定复现。

问题排查

1 猜测zk端口没有监听成功,登录服务器使用netstat查看server打开的三个端口都是正常状态,也使用了telnet测试可以连上。

2 猜测同步节点数不足一半,或者follower连不上leader触发重新选举,但很快就被排除,因为上面说了使用mntr命令查看节点状态都正常,从日志中也未能找到对应日志记录。

3 我们再使用stat来观察server的连接情况,运行zk client发现server收到了client的请求,但是没有回消息,看来原因就是zk server没处理client的请求了。

跟踪到这里,就应该进入源码了,由于对zk源码不熟悉,咨询了某位大佬,建议我们看zk请求处理类CommitProcessor。
在CommitProcessor我们发现了原因,代码如下:

@Override
public void start() {
    ...
    if (workerPool == null) {
        workerPool = new WorkerService("CommitProcWork", numWorkerThreads, true);
    }
    ...
}

public void shutdown() {
    LOG.info("Shutting down");

    halt();

    if (workerPool != null) {
        workerPool.join(workerShutdownTimeoutMS);
    }

    if (nextProcessor != null) {
        nextProcessor.shutdown();
    }
}

在shutdown中调用了 workerPool.join实际上已经将请求处理的开关关闭了,但是并没有将workerPool设置为null。在start方法中会根据workerPool==null来创建WorkerService并开始处理请求。

修改后重新验证解决。

请先登录,查看4条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

JVM 源码分析之一个 Java 进程究竟能创建多少线程
概述虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从 JVM 源码角度来分析,更多的来自于 Linux Kernel 的源码分析,今天要说的是 JVM 里比较常见的一个问题。这个问题可能有
线程池运用不当的一次线上事故
在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高
YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务
【活动结果公布:兑奖见置顶评论】每日一签到,解锁你的PerfMa壕礼
叮......Perfma达人福利发车啦!社区每日签到解锁活动上线啦~除了每日签到必得积分奖励外,还为大家增加了壕礼相赠、解锁Perfma终极大奖等环节奖励 ~来Perfma社区留下你的签到足迹,告诉
使用Top_X插件排查内存过载问题
Top命令是Linux 系统下常用的监控工具,用于实时获取进程级别的 CPU 或内存使用情况。XPocket中的Top_X为Linux Top的增强版,可以显示CPU占用率/负载,CPU及内存进程使用
记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查
在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLan
记一次类加载失败导致线程阻塞问题排查
作为PerfMa解决方案管理部门的技术专家,我在工作遇见过很多各种问题导致的性能问题,并参与了为客户的系统进行性能诊断调优的全过程。这一次碰到了一个类加载失败导致的性能问题。用文字记录下了问题的整个发
一次大量 JVM Native 内存泄露的排查分析(64M 问题)
我们有一个线上的项目,刚启动完就占用了使用 top 命令查看 RES 占用了超过 1.5G,这明显不合理,于是进行了一些分析找到了根本的原因,下面是完整的分析过程,希望对你有所帮助。会涉及到下面这些内容Linux 经典的 64M 内存问题堆内存分析、Native 内存分析的基本套路