Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Bad performace of delay message in rocksdb consumequeue #8765

Open
3 tasks done
yuz10 opened this issue Sep 27, 2024 · 0 comments · May be fixed by #8766
Open
3 tasks done

[Bug] Bad performace of delay message in rocksdb consumequeue #8765

yuz10 opened this issue Sep 27, 2024 · 0 comments · May be fixed by #8766

Comments

@yuz10
Copy link
Member

yuz10 commented Sep 27, 2024

Before Creating the Bug Report

  • I found a bug, not just asking a question, which should be created in GitHub Discussions.

  • I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

  • I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

Ubuntu 24.04

RocketMQ version

5.3.1

JDK Version

1.8

Describe the Bug

Bad performace of delay message in rocksdb consumequeue

Steps to Reproduce

  1. set storeType=defaultRocksDB in broker.conf
  2. send delay messages with delaylever=2 using cd benchmark;sh producer.sh -n localhost:9876 -t testTopic -d true -e 2
  3. watch delay message count using mqadmin topicstatus -n localhost:9876 -t SCHEDULE_TOPIC_XXXX
  4. watch delay message deliver count using cat ${storeRootPath}/config/delayOffset.json

What Did You Expect to See?

delay message are deliverd quick.

What Did You See Instead?

delay message are deliverd slow.

Additional Context

No response

yuz10 added a commit to yuz10/rocketmq that referenced this issue Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant