背景突然收到电话告警，RocketMQ集群的cpu被打到90%以上，马上打开监控系统查看下，cpu直线上升硬盘I/O也在狂飙集群中只有两个节点的cpu暴涨，通过集群信息查下，发现是集群中的两个从节点的cpu暴涨。(我们的集群是4主4从，2个节点部署在同一台机器上，为了省钱)。虽然从节点cpu暴涨不影响整个集群的正常tps写入，还得要清楚是啥原因造成的cpu暴涨。找到对应的集群业务负责人，询问有什么
背景收到业务人员反馈，延迟30s的消息，到时间还没有正常被消费，于是登陆到broker节点上去查看日志，有个ERROR级别的报错：#vim rocketmq-log/stats.log ScheduleMessageService, a message time up, but reput it failed, topic: SCHEDULE_TOPIC_XXXX msgId 016F51324
背景公司有一个topic，消费者160个，都使用了tag来过滤消息，在压测的时候，发现有一个问题，consumerA的积压值在不停的变化，触发了积压告警。而且实际上生产者并没有发送consumerA所使用的tag，理论上不应该有积压才对。在平台上看consumerA的积压情况，到集群通过命令行查看也是一样都显示积压。原因分析假如消费者在消费offset=100的这条tag1消息后，后面连续出现10
在RocketMQ原生控制台中，通过消息检索，能看到消费者的状态有如下四种：NOT_ONLINE ：消费者不在线CONSUMED ：消息已经被投递消费CONSUMED_BUT_FILTERED ：消息已经被投递且被过滤比如，发布端发布消息topicA，tagA，订阅端订阅topicA，tagB, tagA的消息就被集群消费的消费者忽略掉了NOT_CONSUME_YET ：消息未被投递有可能消息发生
环境Namesrv正常情况下都使用域名，便于后期维护。域名IP指向到新IPtest-mq1test.com10.6.65.710.7.3.1test-mq2test.com10.6.66.310.7.4.16test-mq3test.com10.6.66.4210.7.8.20操作1，在新的集群上将Namesrv集群部署好nohup bin/mqnamesrv &2，先将第一个域名解析
背景半夜三更收到公司告警信息，提示是mq生产者发送异常，一直在不停的发送告警信息。根因分析1，查看硬件资源，一切都正常，且是在业务低峰期，排因大流量导致的错误2，根据告警信息去查对应的服务日志，发现一条可疑日志，properties不应该出现这么大3，到mq控制台查看topic情况，发现有积压，积压的offset值为62565613，这条消息被卡住4，通过命令行查看消息的具体内容 bin/mqad
背景收到告警，RocketMQ集群CPU飙高，集群机器只安装了RocketMQ这一个应用，突然CPU飙高，于是登陆到机器上，使用top命令一看究竟1 查看CPU占用高的进程使用top -c 来查看当前的进程信息。默认是按照CUP的使用率进行排序的，闪动得太快， 使用 -d <秒>来控制闪动的速度。top -c -d 52，查找cpu占用高的线程使用 top -Hp <pid>
背景生产环境RocketMQ版本为4.5，需要平滑升级到4.7，部署方式为4主4从。机器配置为：CPU：32C，内存：128G，硬盘：4T以下为集群的一个节点的操作步骤，其他节点升级步骤一致安装4.7版本MQ解压$ mkdir /workspace/apache$ unzip rocketmq-all-4.7.0-bin-release.zip -d /workspace/ &&
将多块硬盘合并注：操作系统使用Centos7.6版本#yum install lvm2 -y && yum -y install parted初始化并挂载硬件#!/bin/bashfor n in b c ;do parted /dev/vd${n} mklabel gptparted /dev/vd${n} mkpart vdb ext4 0 100% << EO
RocketMQ集群节点闪断引起的硬件资源飙高
Rocketmq延迟服务无法正常消费数据
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
