logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: log4j2 2.0-rc1 issues on AIX
Date Fri, 21 Mar 2014 13:01:31 GMT
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 <chrisgwarp@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.popma@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 <chrisgwarp@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.popma@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 <boards@gmail.com> wrote:
> >>>>
> >>>> Perhaps lmax disruptor doesn't work properly in the IBM JVM?
> >>>>
> >>>>> On Tuesday, 18 March 2014, Chris Graham <chrisgwarp@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 <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message