SleepingWaitStrategy runs 100% cpu on Ubuntu VM

[Mark Hoffman]

HI,

I tested a Disruptor 3.4 app using BlockingWaitStrategy and SleepingWaitStrategy on RH and I got the preferred performance using the SleepingWaitStrategy. 

When we moved this app to a docker image running ubuntu 14.4, the SleepWaitStrategy runs at 100%, basically it appears that this call:

 LockSupport.parkNanos(1L); is the same as  LockSupport.parkNanos(0L);

I wrote my own sleep wait strategy that just change the sleep to  TimeUnit.NANOSECONDS.sleep(1L); and it works as expected.

Has anyone else seen this sort of variation between distros?

[Michael Barker]

Apologies for the slow reply.  I have seen LockSupoort.parkNanos cause 100% when running on 32 bit Linux (32 bit Linux uses a slightly different set of syscalls compared with 64 bit).  I've not tested within a docker container.

It is worth noting that TimeUnit.NANOSECONDS.sleep(1L) will effectively degrade to Thread.sleep(1L).  So you will see the reduction in CPU usage, but you will have higher latency than with the SleepingWaitStrategy.

    // From TimeUnit.java

    public void sleep(long timeout) throws InterruptedException {

        if (timeout > 0) {

            long ms = toMillis(timeout);

            int ns = excessNanos(timeout, ms);

            Thread.sleep(ms, ns);

        }

    }

    // From Thread.java

    public static void sleep(long millis, int nanos)

    throws InterruptedException {

        if (millis < 0) {

            throw new IllegalArgumentException("timeout value is negative");

        }

        if (nanos < 0 || nanos > 999999) {

            throw new IllegalArgumentException(

                                "nanosecond timeout value out of range");

        }

        if (nanos >= 500000 || (nanos != 0 && millis == 0)) {

            millis++;

        }

        sleep(millis);

    }

--
You received this message because you are subscribed to the Google Groups "Disruptor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disruptor+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Hoffman]

Thanks for the clarification. Lower cpu is better for our use case than squeezing the very most of the cpu. It's working well with my modified SleepingWaitStrategy.

To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disrupto...@googlegroups.com.