MQ最近老出现broker busy,然后进一步报system busy,有大佬遇到过不?查看sotre.log发现一个特别耗时的写入,大概2s,我怎么判断是磁盘/CPU问题还是内存问题呢?[NOTIFYME]putMessage in lock cost time(ms)=2478
有exporter监控吗, 看看pagecahe的耗时分布呢一般看pagecache的监控一眼可以知道。 可能是磁盘本身性能不足, 也可能是刷盘参数设置不合理, 建议都可以排查下。此回答整理自钉群“群2-Apache RocketMQ 中国开发者 钉钉群”
要判断是磁盘/CPU问题还是内存问题,可以通过一些系统监控工具获取相关信息。
对于磁盘问题,可以通过 iostat
命令来查看硬盘 I/O 相关信息,包括磁盘读写速率、磁盘队列长度、I/O 响应时间等。如果磁盘读写速率低或磁盘队列长度长,就可能是磁盘性能问题。
对于 CPU 问题,可以通过 top
或 htop
命令来查看 CPU 占用率和负载情况。如果 CPU 占用率高或 CPU 负载高,就可能是CPU性能问题。
对于内存问题,可以通过 free
命令来查看系统内存使用情况,如果内存使用率比较高,就可能是内存不足而导致的问题。
另外还有一些常用的系统监控工具,如 sar
、vmstat
、dstat
等,可以综合使用这些工具来获取更全面的系统监控信息,以便更准确地判断系统瓶颈所在。
如果是Linux系统上,可以使用命令top或htop来查看系统的负载情况。在命令行中输入"top"或"htop",会显示当前系统的进程、CPU、内存、磁盘等信息。
对于这种情况,可以先观察MQ的系统负载情况,查看CPU、内存、磁盘等资源的使用情况。如果发现某个资源使用率很高,就可以初步判断出问题所在。
另外,可以通过观察store.log中打印的日志信息,找出耗时的操作所在的代码位置,进一步分析代码逻辑是否存在性能问题。
针对这个特别耗时的写入问题,可以尝试优化写入逻辑,比如使用批量写入的方式,减少单次写入的次数,或者将写入操作移到异步线程中执行,避免阻塞主线程。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
涵盖 RocketMQ、Kafka、RabbitMQ、MQTT、轻量消息队列(原MNS) 的消息队列产品体系,全系产品 Serverless 化。RocketMQ 一站式学习:https://rocketmq.io/