[ https://issues.apache.org/jira/browse/HDDS-11240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872176#comment-17872176 ]
weiming edited comment on HDDS-11240 at 8/9/24 4:11 AM: -------------------------------------------------------- [~smeng] [~ivanandika] [~erose] [~XiChen] [~wanghongbing] Recently we tried to use a higher version of JDK (e.g., 17.0.12), but unfortunately the problem still exists. I suspect this is a bug in JDK and found this issue ( [Gradual CPU Increase Due to ThreadLocal Access|https://bugs.openjdk.org/browse/JDK-8334341]) in [JBS|https://bugs.openjdk.org/secure/Dashboard.jspa] So what should we do next? should we try to remove most of the ThreadLocal-related implementations in the main process and use other methods instead? do you have any ideas? was (Author: JIRAUSER280917): [~smeng] [~ivanandika] [~erose] [~XiChen] [~wanghongbing] Recently we tried to use a higher version of JDK (e.g., 17.0.12), but unfortunately the problem still exists. I suspect this is a bug in JDK and found this issue ( [Gradual CPU Increase Due to ThreadLocal Access|https://bugs.openjdk.org/browse/JDK-8334341] ) in [JBS|https://bugs.openjdk.org/secure/Dashboard.jspa] So what should we do next? should we try to remove most of the ThreadLocal-related implementations in the main process and use other methods instead? do you have any ideas? > High cpu usage on ReadWrite locks in JDK17 > ------------------------------------------ > > Key: HDDS-11240 > URL: https://issues.apache.org/jira/browse/HDDS-11240 > Project: Apache Ozone > Issue Type: Bug > Components: OM > Affects Versions: 1.4.0 > Environment: JDK: > openjdk 17.0.2 2022-01-18 > OpenJDK Runtime Environment (build 17.0.2+8-86) > OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) > Ozone: > 1.4.0 > > Reporter: weiming > Assignee: Tanvi Penumudy > Priority: Major > Attachments: flamegraph.profile.html, > image-2024-07-28-20-17-58-466.png, image-2024-07-30-09-32-16-320.png > > > That will cause threads on the following stack trace to consume a lot of CPU: > "IPC Server handler 7 on default port 9862" #3994 daemon prio=5 os_prio=0 > cpu=5403833.36ms elapsed=653145.54s tid=0x00007fa03fdd2a00 nid=0x921f9 > runnable [0x00007fa0ca3fd000] > java.lang.Thread.State: RUNNABLE > at > java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntry(java.base@17.0.2/ThreadLocal.java:632) > at > java.lang.ThreadLocal$ThreadLocalMap.remove(java.base@17.0.2/ThreadLocal.java:516) > at java.lang.ThreadLocal.remove(java.base@17.0.2/ThreadLocal.java:242) > at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(java.base@17.0.2/ReentrantReadWriteLock.java:430) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(java.base@17.0.2/AbstractQueuedSynchronizer.java:1094) > at > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(java.base@17.0.2/ReentrantReadWriteLock.java:897) > at > org.apache.hadoop.ozone.upgrade.AbstractLayoutVersionManager.needsFinalization(AbstractLayoutVersionManager.java:182) > at > org.apache.hadoop.ozone.om.request.validation.ValidationCondition$1.shouldApply(ValidationCondition.java:39) > at > org.apache.hadoop.ozone.om.request.validation.RequestValidations.lambda$0(RequestValidations.java:110) > at > org.apache.hadoop.ozone.om.request.validation.RequestValidations$$Lambda$839/0x00000008013cda80.test(Unknown > Source) > > [^flamegraph.profile.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org For additional commands, e-mail: issues-h...@ozone.apache.org