ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Striped pool configuration
Date Fri, 16 Dec 2016 11:39:57 GMT
Andrey,

Yes, "striped pool" is a thread pool where every thread operate on a single
queue. This is the only similarity with FJP, as we do not perform real
fork-join in our pools. Having said that, I do not see why we might want to
compare our pool with FJP.

As per throughput - it is improved because instead of accessing a
single *BlockingQueue
*based on *ReentrantLock*, every thread has separate queue. And it is
designed in a way, that under load NIO threads usually enqueue tasks and
worker threads dequeue tasks without blocking, and even without CAS-loops,
thanks to MPSC semantics.

Vladimir.

On Fri, Dec 16, 2016 at 2:21 PM, Andrey Mashenkov <
andrey.mashenkov@gmail.com> wrote:

> Vladimir,
>
> As I understand "striped pool" is a array of single-threaded pools. Do you
> have an understanding why throughput increased up to 40%?
> It looks like it is due to every thread has its own task queue.
>
> As far as I know, there is ForkJoinPool in JDK, FJP implements
> ExecutorService interface, has striped tasks queue, has task-stealing
> mechanics.
>
> Can we run Ignite performance tests b\w using "striped pool" and FJP?
>
> On Fri, Dec 16, 2016 at 11:17 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > Folks,
> > Can we move all discussions aside of pool config to separate threads,
> > please? :-)
> >
> > Dima,
> > I heard your concern about configuration complexity. But I do not see any
> > problem at all. Whether to use striped pool or not is a matter of
> > fine-grained tuning. We will set sensible defaults (i.e. enabled striped
> > pool), so 99% of users will never know that a concept of "stiped pool"
> even
> > exists.
> >
> > Striped and non-striped approaches have their own pros and cons.
> >
> > Striped:
> > + Better overall throughput (up to +40% compared to non-striped);
> > - Less predictable latency - user can have bad numbers even on moderate
> > load (e.g. consider updates on a large affinity co-located object graph).
> > Benchmarks demonstrate this clearly.
> > - Higher memory footprint, because in striped mode we pre-start all the
> > threads. On high-end machines it may end up in wasting of hundrends of
> > megabytes of RAM.
> > - As a result of previous point, it is not well-suited for clients, which
> > may require small memory footprint and low startup time.
> >
> > Non-striped:
> > - Worse throughput due to very high contention on BlockingQueue.
> > + No waste on idle threads.
> >
> > I would propose the following final design for this:
> >
> > - Introduce *"boolean systemThreadPoolStriped"* property;
> > - Set it to *"true"* for servers by default;
> > - Set it to *"false"* for clients by default.
> >
> > Yakov,
> > I still do not get your point about (system + public) pools approach.
> >
> > Vladimir.
> >
> > On Fri, Dec 16, 2016 at 9:29 AM, Yakov Zhdanov <yzhdanov@apache.org>
> > wrote:
> >
> > > >In my view, we should hide most of such configuration intricacies from
> > > users,
> > > and select an appropriate thread pool for each task ourselves. Will
> this
> > be
> > > possible?
> > >
> > > We already do this. We take decision internally on where to route the
> > > request.
> > >
> > > SoE, my answers below.
> > >
> > > >How did the striped pool show itself for transactional updates that
> > > involve 2 phase commit? Any benefits or degradation?
> > >
> > > Even better than for atomic - up to ~50% improvement.
> > >
> > > >Here we should decide what’s more important for us - throughout or
> > > latency. If to execute SQL queries in the striped pool using multiple
> > > partitioned threads then, for sure, it will affect latency of other
> > > operations that are sitting in the queue waiting for their time to be
> > > processed but, on the other hand, the overall throughput of the
> platform
> > > should be improved because the operations will be less halted all the
> > time
> > > by synchronization needs.
> > >
> > > >VoltDB decided to go for with the throughput while our current
> > > architecture is mostly latency based.
> > >
> > > What do you mean by "using several partition threads"? I am pretty sure
> > > that if we do as you suggest we will have degradation here instead of
> > > boost:
> > >
> > > sql-query-put
> > > after: 77,344.83
> > > before: 53,578.78
> > > delta: 30.73%
> > >
> > > sql-query-put-offheap
> > > after 32,212.30
> > > before 25,322.43
> > > delta 21.39%
> > >
> > > --Yakov
> >
>
>
>
> --
> С уважением,
> Машенков Андрей Владимирович
> Тел. +7-921-932-61-82
>
> Best regards,
> Andrey V. Mashenkov
> Cerr: +7-921-932-61-82
>

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