Su的技术博客

  • 首页
  • 原创
  • 视频
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • AI
  • Other
  • 工具
    • AI工具集
    • 工具清单
    • JSON在线格式化
    • JSON在线比较
    • SQL在线格式化
  • 打赏
  • 关于
路很长,又很短
  1. 首页
  2. Java
  3. 正文
                           

【原创】RocketMQ 很慢?引出了一个未解之谜

2020-06-08 2082点热度 0人点赞 0条评论













点击上方蓝色字关注我们~

前段时间发现,在使用RockerMQ console时,查询消息的时候出现很慢,查询耗时大于10秒,少则5、6秒,多则14+秒。


如下图:


这到底是为什么?查询消息为啥会出现这么大的耗时?


当前使用的开发环境:操作系统是Windows10,JDK8,RocketMQ为4.5.2。


在其它机器上则没有此问题,也在本机器上的虚拟机VMware上安装的Linux部署了RocketMQ 和 console,并且验证是没问题的。


那么到底我的机器是怎么了???

由于当前是接口的耗时问题,我们并不知道耗时主要在哪个地方,所以使用Arthas来跟踪下调用链的耗时。


使用trace命令:


trace命令



方法内部调用路径,并输出方法路径上的每个节点上耗时。

trace 命令能主动搜索 class-pattern/method-pattern 对应的方法调用路径,渲染和统计整个调用链路上的所有性能开销和追踪调用链路。


trace org.apache.rocketmq.console.service.impl.MessageServiceImpl queryMessageByTopic

从当前调用路径得到主要耗时在于:DefaultMQPullConsumer构造器初始化 + DefaultMQPullConsumer启动耗时。那么接下来我们继续往内部跟进。
此时我们关注下DefaultMQPullConsumer构造器初始化:
trace org.apache.rocketmq.client.consumer.DefaultMQPullConsumer <init>

从构造器初始化入口看,耗时并不大。

那么接下来再看下DefaultMQPullConsumer的启动方法:




[E] 开启正则表达式匹配,默认为通配符匹配




trace -E  org.apache.rocketmq.client.consumer.DefaultMQPullConsumer start

trace -E  org.apache.rocketmq.client.consumer.DefaultMQPullConsumer <init>|start

接着发现耗时主要是在获取MQClientInstance实例。

trace org.apache.rocketmq.client.impl.MQClientManager getAndCreateMQClientInstance 

trace org.apache.rocketmq.client.ClientConfig cloneClientConfig

接着看ClientConfig#cloneClientConfig方法:


public ClientConfig cloneClientConfig() {
    ClientConfig cc = new ClientConfig();
    cc.namesrvAddr = namesrvAddr;
    cc.clientIP = clientIP;
    cc.instanceName = instanceName;
    cc.clientCallbackExecutorThreads = clientCallbackExecutorThreads;
    cc.pollNameServerInterval = pollNameServerInterval;
    cc.heartbeatBrokerInterval = heartbeatBrokerInterval;
    cc.persistConsumerOffsetInterval = persistConsumerOffsetInterval;
    cc.unitMode = unitMode;
    cc.unitName = unitName;
    cc.vipChannelEnabled = vipChannelEnabled;
    cc.useTLS = useTLS;
    cc.namespace = namespace;
    cc.language = language;
    return cc;
}


可以看到很多赋值操作,这些可以不关注,只要关注new ClientConfig():


trace org.apache.rocketmq.client.ClientConfig <init>

可以看到主要耗时在3~4秒,并且耗时主要是这个工具类方法:RemotingUtil#getLocalAddress

  trace org.apache.rocketmq.remoting.common.RemotingUtil getLocalAddress

到现在,已经跟踪到JDK方法调用了:NetworkInterface#getNetworkInterfaces。


接着想查看JDK函数调用:

trace --skipJDKMethod false java.net.NetworkInterface getNetworkInterfaces




--skipJDKMethod <value>  skip jdk method trace, default value true.

默认情况下,trace不会包含jdk里的函数调用,如果希望trace jdk里的函数,需要显式设置--skipJDKMethod false。




此时不能跟踪,那么根据4点提示排查和issue:https://github.com/alibaba/arthas/issues/47

https://github.com/alibaba/arthas/issues/807

最后确定需要开启unsafe。

options unsafe true

开启完成。

再次执行,即可看到jdk的调用链了。


到这里,算是把RocketMQ console查询慢的罪魁祸首找到了:在获取本机网卡接口时,出现耗时时间长。这其实也算是jdk跟操作系统层面的意思了,与中间件RocketMQ无关,一开始我是怀疑是不是持久化存储在加载时慢的可能(基本排除)。


那么为什么会调用当前操作系统的网卡接口时会出现耗时严重呢?

此时关注到了java.net.NetworkInterface#getNetworkInterfaces

public static Enumeration<NetworkInterface> getNetworkInterfaces()
    throws SocketException 
{
    final NetworkInterface[] netifs = getAll();
    // specified to return null if no network interfaces
    if (netifs == null)
        return null;
    return new Enumeration<NetworkInterface>() {
        private int i = 0;
        public NetworkInterface nextElement() {
            if (netifs != null && i < netifs.length) {
                NetworkInterface netif = netifs[i++];
                return netif;
            } else {
                throw new NoSuchElementException();
            }
        }
        public boolean hasMoreElements() {
            return (netifs != null && i < netifs.length);
        }
    };
}
private native static NetworkInterface[] getAll() throws SocketException;

可以看到jdk函数已经调用到了native方法,也就是jdk底层的实现(c/c++)了,跟操作系统非常紧密。

接着debug进getNetworkInterfaces方法查看到底有哪些网卡接口:


一查发现竟然有81个!接着查看本机的网络适配器:

本机Windows上有Wlan、VPN、VMware等网络适配器。


最后事实就是跟他们有关,我把相应的适配器禁用之后,重新调用NetworkInterface#getNetworkInterfaces,此时耗时从3+秒降到几百毫秒。


最后,很遗憾还是没能剖析出为什么Windows下调用网卡接口native方法会出现那么大耗时。并且肯定跟我的机器有关,因为其他机器验证没有问题。


如果要剖析原因,就得需要有c/c++更加底层的功底才能搞定吧?


如果你有遇过知道怎么解决、或熟悉底层实现或者有更好的思路麻烦留言指导下。(抱拳)





总结


  • Windows下可能容易出现一些非正常问题,竟然也能给我遇到这个^@^。幸好一般使用Windows还是比较少,除非是开发机器较多,Linux(unix)部署RocketMQ等中间件还是很稳的。
  • 使用Arthas trace可以跟踪方法的调用路径,并且追踪每一步的耗时,可以方便的排查瓶颈问题。
  • -E参数支持正则表达式匹配;--skipJDKMethod false支持包含JDK的函数调用;跟踪jdk函数等,如果找不到对应类或者方法,可能需要开启unsafe。



回复公众号【资料】获得干货资料集锦:技术ppt、IT大会资料、架构、分布式资料等。

推荐好文

1、互联网Code Review最佳实践分享

2、dubbo面试题!会这些,说明你看懂了dubbo源码

3、Kafka面试题!掌握它才说明你真正懂Kafka
4、
Netty 5.0为啥被舍弃?原因竟然是...
5、
中台之上——业务架构系列【汇总】

6、必备瑞士军刀IDEA插件,你使用了哪些

7、线上热更新代码只需3步 Arthas实战

8、Eureka源码剖析之七:架构&面试题【总结】

9、互联网工程师应该用这种姿势打印日志

10、加入:互联网基础/架构交流群

-关注搬运工来架构,与优秀的你一同进步-

如果喜欢这篇文章可以点在看哦↘

本文仅供学习!所有权归属原作者。侵删!文章来源: 搬运工来架构

更多文章:

  1. 全链路压测之影子库及ShardingSphere实现影子库源码剖析
  2. JVM 内存分析工具 MAT 的深度讲解与实践——进阶篇(长文)
  3. Chrome插件(扩展)开发全攻略2.6w字,看这篇就够了!
  4. 2021.07.13 我们是这样崩的
  5. ElasticSearch之各大版本演进,发布8.0.0 Alpha 2版本
  6. 记一次网络请求连接超时的事故
  7. JVM垃圾回收器CMS原理与调优
  8. 仅使用set属性值就把数据库数据给改了
  9. 笔记08 | 搜狗面试题:IO多路复用之select、poll、epoll的区别
  10. JVM 内存分析神器 MAT: Incoming Vs Outgoing References 你真的了解吗?
标签: 原创
最后更新:2020-06-08

Cocodroid

专注Java后端,分享技术。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

广告
最新 热点 推荐
最新 热点 推荐
干货 | 论Elasticsearch数据建模的重要性 马蜂窝消息总线——面向业务的消息服务设计 基于 MySQL Binlog 实现可配置的异构数据同步 视频笔记:Google发布Agent2Agent协议 视频笔记:什么是微服务,为什么是微服务? 视频笔记:什么是AI 智能体? 视频笔记:什么是Flink? 如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具
Elasticsearch 使用误区之六——富文本内容写入前不清洗基于 MySQL Binlog 实现可配置的异构数据同步马蜂窝消息总线——面向业务的消息服务设计干货 | 论Elasticsearch数据建模的重要性你可以不用RxJava,但必须得领悟它的思想!如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具视频笔记:什么是Flink?视频笔记:什么是AI 智能体?
API 设计巅峰对决:GraphQL VS REST 谁更胜一筹? Elasticsearch 中 _count 和 _stats 文档数量不一致的困惑与解决方案 9.包和命名空间(译) 浅析Redis大Key Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用! RocketMQ消息回溯实践与解析 系统设计 | 基于读者反馈的补充更新 (1) 笔记 | 面试官问我高并发的问题:并发编程的三大挑战

CRUD (1) Event Sourcing (1) graphql (1) id (1) NoSQL (1) quarkus (1) rest (1) RocketMQ (2) Spring Boot (1) zk (1) zookeeper (1) 上下文 (1) 事务消息 (1) 二级缓存 (1) 值对象 (1) 关系数据库 (1) 分布式缓存 (1) 原子性 (1) 唯一ID (1) 商品 (1) 多对多 (1) 子域 (1) 字符集 (1) 客户端心跳 (1) 幂等 (2) 干货 (1) 并发 (1) 应用场景 (1) 应用架构图 (1) 康威定律 (2) 异步复制 (1) 微服务架构 (2) 总体方案 (1) 技术方案 (2) 技术架构 (2) 技术架构图 (1) 技能 (1) 持续集成 (1) 支撑域 (1) 故障恢复 (1) 数据架构图 (1) 方案选型 (1) 日记 (1) 服务发现 (1) 服务治理 (1) 服务注册 (2) 机房 (1) 核心域 (1) 泄漏 (1) 洋葱架构 (1) 消息队列 (5) 源码剖析 (1) 灰度发布 (1) 熔断 (1) 生态 (1) 画图工具 (1) 研发团队 (1) 线程 (2) 组织架构 (1) 缓存架构 (1) 编码 (1) 视频 (18) 读写分离 (1) 贵州 (1) 软件设计 (1) 迁移 (1) 通用域 (1) 集群化 (1) 雪花算法 (1) 顺序消息 (1)

推荐链接🔗
  • AI工具集
  • 工具箱🛠️

COPYRIGHT © 2014-2025 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2

x