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 08:17:20 GMT
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

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