ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Striped pool configuration
Date Fri, 16 Dec 2016 17:37:01 GMT
Well, looks like I’m a bit confused with what is meant under the “striped pool”.

Vladimir, referring to your explanation

> Yes, "striped pool" is a thread pool where every thread operate on a single
> queue.

please answer on the following:

- Does a queue belong to a specific cache partition? In other words, every partition will
have its own processing thread which is similar to what HZ and VoltDB do.

- If the answer to the question above is negative then how do we decide where a specific cache
message should fall for processing?


—
Denis

> On Dec 16, 2016, at 3:39 AM, Vladimir Ozerov <vozerov@gridgain.com> wrote:
> 
> 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
View raw message