[jira] [Comment Edited] (IGNITE-15528) JRaft creates at least 4 threads for every raft group on a leader
[
https://issues.apache.org/jira/browse/IGNITE-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448988#comment-17448988
]
Mirza Aliev edited comment on IGNITE-15528 at 11/25/21, 7:41 AM:
-
[~ascherbakov] Thank you for your contribution! Changes look good to me.
was (Author: maliev):
[~ascherbakov] Thank you for your conteribution! Changes look good to me.
> 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
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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. There is an issue in original JRaft repo with some close ideas
> https://github.com/sofastack/sofa-jraft/issues/672
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15528) JRaft creates at least 4 threads for every raft group on a leader
[
https://issues.apache.org/jira/browse/IGNITE-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437924#comment-17437924
]
Alexey Scherbakov edited comment on IGNITE-15528 at 11/3/21, 2:59 PM:
--
This patch includes a shared pool for timers and a refactoring for explicit
shared pool mods.
In this mode node will not manage it's resources, otherwise it will cleanup
everything on node stop.
As a result of a patch threads are not longer spawn during test runs. I was
able to susccesfully start 500 raft groupusing a small amount of heap.
Ready for review.
was (Author: ascherbakov):
Ready for review.
> 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
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
>
> 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. There is an issue in original JRaft repo with some close ideas
> https://github.com/sofastack/sofa-jraft/issues/672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
