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

BlockingWaitStrategy CPU 100% #460

Open
QinZhiWenXuan opened this issue Sep 22, 2023 · 2 comments
Open

BlockingWaitStrategy CPU 100% #460

QinZhiWenXuan opened this issue Sep 22, 2023 · 2 comments

Comments

@QinZhiWenXuan
Copy link

QinZhiWenXuan commented Sep 22, 2023

I used BlockingWaitStrategy in my code,it makes my project use CPU 100%

I use it for exception alert.Our system tps is not high,Fewer exceptions.
As you know,I didn't use YieldingWaitStrategy,I used BlockingWaitStrategy.
It performed so well for a long time, But today it used up my CPU.

image

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <dependencies>
    <!-- Omit other dependencies here -->
    <!-- disruptor -->
    <dependency>
        <groupId>com.lmax</groupId>
        <artifactId>disruptor</artifactId>
        <version>4.0.0.RC1</version>
    </dependency>
    </dependencies>
</project>
    public void init() {
        this.disruptor = new Disruptor<>(
                new ReportPayloadFactory(),
                1024 * 4,
                new NamedThreadFactory("owl-disruptor-worker-", Boolean.TRUE),
                ProducerType.MULTI,
                new BlockingWaitStrategy()
        );
        this.disruptor
                .handleEventsWith(new ReportConsumer(this.messageService))
                .then(new ClearingReportPayloadEventHandler())
        ;
        this.disruptor.start();
        this.producer = new ReportProducer(this.disruptor.getRingBuffer());
    }

Desktop (please complete the following information):

  • OS: [Linux]
  • Version [4.0.0.RC1]
  • JVM Version [openjdk version "11.0.6"]
@MendelMonteiro
Copy link
Contributor

MendelMonteiro commented Sep 23, 2023

You should profile the CPU usage just to be sure where the time is being taken.

Having said that I suspect that if your first consumer is much slower than your second consumer the second blocking wait strategy will be spinning in this loop waiting for a dependent sequence: https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/BlockingWaitStrategy.java#L45

In the .NET port there is an implementation that will not use 100% CPU as it will actually sleep the thread occasionally instead of just yielding.

https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/BlockingSpinWaitWaitStrategy.cs

@QinZhiWenXuan
Copy link
Author

You should profile the CPU usage just to be sure where the time is being taken.

Having said that I suspect that if your first consumer is much slower than your second consumer the second blocking wait strategy will be spinning in this loop waiting for a dependent sequence: https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/BlockingWaitStrategy.java#L45

In the .NET port there is an implementation that will not use 100% CPU as it will actually sleep the thread occasionally instead of just yielding.

https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/BlockingSpinWaitWaitStrategy.cs

Thank you for your reply.Maybe I didn't describe it clearly.My business scenario is a simple asynchronous alarm,Each consumer only delivers messages to MQ.There should be no chance of any one being blocked.Let me refer to the implementation.Finally thank you anyway

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

No branches or pull requests

2 participants