[
https://issues.apache.org/jira/browse/KAFKA-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531100#comment-16531100
]
Damien Gasparina edited comment on KAFKA-7129 at 7/3/18 9:34 AM:
-----------------------------------------------------------------
Isn't that more a JVM / Library issue more than Kafka issue? e.g.
https://bugs.openjdk.java.net/browse/JDK-6515172. I guess container/cgroups
will create more issue with memory as, if I remember correctly, there is no
safe way to get the limitation
(https://fabiokung.com/2014/03/13/memory-inside-linux-containers/)
was (Author: dabz):
Isn't that more a JVM / Library issue more than Kafka issue? e.g.
https://bugs.openjdk.java.net/browse/JDK-6515172. I guess container/cgroups
will create more issue with memory as, if I remember, there is no safe way to
get the limitation
(https://fabiokung.com/2014/03/13/memory-inside-linux-containers/)
> Dynamic default value for number of thread configuration
> --------------------------------------------------------
>
> Key: KAFKA-7129
> URL: https://issues.apache.org/jira/browse/KAFKA-7129
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Reporter: Damien Gasparina
> Priority: Minor
>
> There are properties in the broker to change the number of thread of a
> component (e.g. _num.replica.fetchers_ or _num.network.threads_). After
> discussing with [~astubbs], it seems that the default values are optimized
> for an 8 CPU machine and might not be optimized for larger machine (e.g. 48
> cores).
> For those larger machine, an admin need to tune them to be able to use all
> resources of the host.
> Having dynamic default value (e.g. _num.replica.fetchers_ = _ceil(number of
> core / 8)_, etc...) instead of static (e.g. _num.replica.fetchers =1_) could
> be a more efficient strategy to have default values optimized for different
> kind of deployment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
