[
https://issues.apache.org/jira/browse/KAFKA-19470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
terrytlu updated KAFKA-19470:
-----------------------------
Description:
We see that the broker has a performance bottleneck when processing requests in
kafka 2.8.2 version + jdk 11 environment. The CPU profiler is as follows:
!image-2025-07-04-19-05-51-900.png|width=1065,height=489!
After research, we found that this is a problem with jdk11 but without
resolution [https://bugs.openjdk.org/browse/JDK-8266964] StackWalker has a
performance degradation for jdk11.
When creating every logger, log4j2 will invoke StackWalker, the following is
the performance data observed using arthas. It takes about 60ms to create each
logger.
!image-2025-07-04-19-25-57-774.png|width=725,height=367!
Applications should set the logger variable of each class to static to avoid
wasting performance on creating loggers.
seen in KAFKA-15141, the corresponding classes
IncrementalFetchContext/DelayedProduce/SessionlessFetchContext have been
processed, but I think a better approach should be to optimize the trait
Logging, we can introduce a static Map object to cache the duplicate loggers.
was:
We see that the broker has a performance bottleneck when processing requests in
kafka 2.8.2 version + jdk 11 environment. The CPU profiler is as follows:
!image-2025-07-04-19-05-51-900.png|width=1065,height=489!
After research, we found that this is a problem with jdk11 but without
resolution [https://bugs.openjdk.org/browse/JDK-8266964] StackWalker has a
performance degradation for jdk11.
When creating every logger, log4j2 will invoke StackWalker, which could be a
bottleneck of application. The following is the performance data observed using
arthas. It takes about 60ms to create each logger.
!image-2025-07-04-19-25-57-774.png|width=725,height=367!
Applications should set the logger variable of each class to static to avoid
wasting performance on creating loggers.
seen in KAFKA-15141, the corresponding classes
IncrementalFetchContext/DelayedProduce/SessionlessFetchContext have been
processed, but I think a better approach should be to optimize the trait
Logging, we can introduce a static Map object to cache the duplicate loggers.
> Avoid creating loggers repeatedly to affect the performance of request
> processing
> ---------------------------------------------------------------------------------
>
> Key: KAFKA-19470
> URL: https://issues.apache.org/jira/browse/KAFKA-19470
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.8.2
> Reporter: terrytlu
> Priority: Major
> Attachments: 20250704-145553.html, image-2025-07-04-19-05-51-900.png,
> image-2025-07-04-19-25-57-774.png
>
>
> We see that the broker has a performance bottleneck when processing requests
> in kafka 2.8.2 version + jdk 11 environment. The CPU profiler is as follows:
> !image-2025-07-04-19-05-51-900.png|width=1065,height=489!
> After research, we found that this is a problem with jdk11 but without
> resolution [https://bugs.openjdk.org/browse/JDK-8266964] StackWalker has a
> performance degradation for jdk11.
> When creating every logger, log4j2 will invoke StackWalker, the following is
> the performance data observed using arthas. It takes about 60ms to create
> each logger.
> !image-2025-07-04-19-25-57-774.png|width=725,height=367!
> Applications should set the logger variable of each class to static to avoid
> wasting performance on creating loggers.
> seen in KAFKA-15141, the corresponding classes
> IncrementalFetchContext/DelayedProduce/SessionlessFetchContext have been
> processed, but I think a better approach should be to optimize the trait
> Logging, we can introduce a static Map object to cache the duplicate loggers.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
