[
https://issues.apache.org/jira/browse/IGNITE-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-15528:
---------------------------------
Description:
When we create a raft group on a leader, jraft creates at least 4 threads for
every raft group: one thread for {{electionTimer}}, {{voteTimer}},
{{stepDownTimer}}, and {{snapshotTimer}}. To be more precise, every timer is an
instance of {{HashedWheelTimer}}, which creates one thread:
{code:java}
private final Worker worker = new Worker();
...
workerThread = threadFactory.newThread(worker);
{code}
This fact leads to restrictions on the number of partitions that might be
created, as far as every partition is associated with a raft group. For
example, one table with 1024 partitions leads to at least 4096 threads on a
single node.
Changing {{HashedWheelTimer}} to {{DefaultTimer}} with shared pool won't make
any sense, as far as the workload of the shared executor likely will lead to
instability of cluster because threads are timer threads (election timer, for
example).
A possible solution is to implement batched handling of raft groups requests,
like {{appendEntriesRequest}}. In this approach, timers could be shared by raft
groups.
was:
When we create a raft group on a leader, jraft creates at least 4 threads for
every raft group: one thread for {{electionTimer}}, {{voteTimer}},
{{stepDownTimer}}, {{snapshotTimer}}. To be more precise, every timer is an
instance of {{HashedWheelTimer}}, which creates one thread:
{code:java}
private final Worker worker = new Worker();
...
workerThread = threadFactory.newThread(worker);
{code}
This fact leads to restrictions on the number of partitions that might be
created, as far as every partition is associated with a raft group. For
example, one table with 1024 partitions leads to at least 4096 threads on a
single node.
Changing {{HashedWheelTimer}} to {{DefaultTimer}} with shared pool won't make
any sense, as far as the workload of the shared executor likely will lead to
instability of cluster because threads are timer threads (election timer, for
example).
A possible solution is to implement batched handling of raft groups requests,
like {{appendEntriesRequest}}. In this approach, timers could be shared by raft
groups.
> JRaft creates at least 4 threads for every raft group on a leader
> ------------------------------------------------------------------
>
> Key: IGNITE-15528
> URL: https://issues.apache.org/jira/browse/IGNITE-15528
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mirza Aliev
> Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> When we create a raft group on a leader, jraft creates at least 4 threads for
> every raft group: one thread for {{electionTimer}}, {{voteTimer}},
> {{stepDownTimer}}, and {{snapshotTimer}}. To be more precise, every timer is
> an instance of {{HashedWheelTimer}}, which creates one thread:
> {code:java}
> private final Worker worker = new Worker();
> ...
> workerThread = threadFactory.newThread(worker);
> {code}
> This fact leads to restrictions on the number of partitions that might be
> created, as far as every partition is associated with a raft group. For
> example, one table with 1024 partitions leads to at least 4096 threads on a
> single node.
> Changing {{HashedWheelTimer}} to {{DefaultTimer}} with shared pool won't make
> any sense, as far as the workload of the shared executor likely will lead to
> instability of cluster because threads are timer threads (election timer, for
> example).
> A possible solution is to implement batched handling of raft groups requests,
> like {{appendEntriesRequest}}. In this approach, timers could be shared by
> raft groups.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
