Oh cool, nanosecond scale scheduler? Sorry, I'm an IBM noob, though a
family member is an old mainframe expert.
On Thursday, 20 March 2014, Chris Graham <chrisgw...@gmail.com> wrote:
> +1 to the default of Block!
>
> 1ns is too small. No wonder is sucked CPU. :-)
>
> Thanks for looking!
>
> -Chris
>
> Sent from my iPhone
>
> On 21/03/2014, at 1:32 PM, Remko Popma <remko.po...@gmail.com> wrote:
>
> > Took another look at the Disruptor SleepingWait strategy. It actually
> uses
> > a back-off strategy. From the javadoc:
> >
> > Sleeping strategy that initially spins, then uses a Thread.yield(), and
> > eventually for the minimum number of nanos the OS and JVM will allow
> while
> > the {@link com.lmax.disruptor.EventProcessor}s are waiting on a barrier.
> > This strategy is a good compromise between performance and CPU resource.
> > Latency spikes can occur after quiet periods.
> >
> > The Disruptor SleepingWait strategy code eventually calls LockSupport.
> > parkNanos(1L);
> > Different platforms have different timer resolution (I think Windows
> cannot
> > go smaller than ~15 millis), and it is possible that AIX has a more
> > accurate clock.
> >
> > I'm beginning to think perhaps BlockingWait should be the default for
> log4j.
> >
> > On Fri, Mar 21, 2014 at 9:33 AM, Chris Graham <chrisgw...@gmail.com>
> wrote:
> >
> >> The AIX system clock is not the same base time as most Intel boxes.
> What is
> >> the sleep time in the sleep strategy? If it's being derived, it might be
> >> too small. ???
> >>
> >> Just a thought.
> >>
> >> To further complicate matters, this particular lpar was uncapped, which
> >> means that it can steal CPU from other lpars that are not as busy. So
> the
> >> number of active CPU's can dynamically vary.
> >>
> >> -Chris
> >>
> >>
> >>
> >> On Fri, Mar 21, 2014 at 9:01 AM, Remko Popma <remko.po...@gmail.com>
> >> wrote:
> >>
> >>> No, it turned out that the docs for Apache Archiva were incorrect and
> the
> >>> WaitStrategy was effectively still SleepingWaitStrategy. Using the
> >> correct
> >>> config to specify BlockingWaitStrategy solved the issue. (LOG4J2-571)
> >>>
> >>> FYI, the wait strategy determines what the consumer thread does when
> the
> >>> queue is empty & it's waiting for events. Some specialized apps want to
> >>> avoid the latency of waking up a blocked thread, so there are a number
> of
> >>> options with different trade-offs, with busy spin on one end of the
> >>> spectrum and blocking on the other. For log4j I reduced the set of
> >>> available options (no busy spin), and choose SleepingWait as the
> >> default.
> >>> This had the best performance in my testing. Until now I hadn't seen
> any
> >>> excessive CPU usage.
> >>>
> >>> Sent from my iPhone
> >>>
> >>>> On 2014/03/20, at 22:10, Matt Sicker <boa...@gmail.com> wrote:
> >>>>
> >>>> Perhaps lmax disruptor doesn't work properly in the IBM JVM?
> >>>>
> >>>>> On Tuesday, 18 March 2014, Chris Graham <chrisgw...@gmail.com>
> wrote:
> >>>>>
> >>>>> JStack is a Sun thing. This is the IBM JDK on AIX.
> >>>>> I've run the tprof command twice and verified it.
> >>>>>
> >>>>> The full work though follows.
> >>>>>
> >>>>> The output from topas (same as top, effectively) is:
> >>>>>
> >>>>> Topas Monitor for host: XXXXXXXXXXXXXXX EVENTS/QUEUES
> >>> FILE/TTY
> >>>>> Wed Mar 19 14:49:55 2014 Interval: 2 Cswitch 3581
> >>>>> Readch 686
> >>>>> Syscall 2763
> >> Writech
> >>>>> 1378
> >>>>> CPU User% Kern% Wait% Idle% Physc Entc Reads 7
> >>>>> Rawin 0
> >>>>> ALL 48.8 1.2 0.0 50.1 1.03 51.7 Writes 5
> >>>>> Ttyout 643
> >>
--
Matt Sicker <boa...@gmail.com>
