You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "Yaolong Liu (Jira)" <ji...@apache.org> on 2022/07/19 07:10:00 UTC
[jira] [Comment Edited] (RATIS-1603) TimeoutScheduler can have a huge amount of threads and cause OOM
[ https://issues.apache.org/jira/browse/RATIS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568372#comment-17568372 ]
Yaolong Liu edited comment on RATIS-1603 at 7/19/22 7:09 AM:
-------------------------------------------------------------
[~szetszwo] I found that a lot of independent threadpool are indeed generated, see the screenshot
!screenshot-1.png!
I don't think so many thread pools are as expected, and setting the corePoolSize of this thread pool to 0 should alleviate the problem. But is there a bug in creating the thread pool? I'm guessing there might be something wrong here, can you help take a look, thanks!
!image-2022-07-19-15-09-06-529.png!
was (Author: JIRAUSER280039):
[~szetszwo] I found that a lot of independent threadpool are indeed generated, see the screenshot
!screenshot-1.png!
I don't think so many thread pools are as expected, and setting the corePoolSize of this thread pool to 0 should alleviate the problem. But is there a bug in creating the thread pool? I'm guessing there might be something wrong here, can you help take a look, thanks!
!screenshot-2.png!
> TimeoutScheduler can have a huge amount of threads and cause OOM
> ----------------------------------------------------------------
>
> Key: RATIS-1603
> URL: https://issues.apache.org/jira/browse/RATIS-1603
> Project: Ratis
> Issue Type: Bug
> Components: util
> Affects Versions: 2.0.0
> Reporter: Baolong Mao
> Assignee: Tsz-wo Sze
> Priority: Major
> Attachments: image-2022-06-29-09-33-28-818.png, image-2022-06-29-09-37-07-089.png, image-2022-07-19-15-09-06-529.png, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> !image-2022-06-29-09-33-28-818.png!
> The callstack are same for the 20k threads
> {code:java}
> "java.util.concurrent.ThreadPoolExecutor$Worker@64f771ea[State = -1, empty queue]" #486880 daemon prio=5 os_prio=0 cpu=0.14ms elapsed=35.35s allocated=1696B defined_classes=0 tid=0x00007f136fb65800 nid=0x2130e1 waiting on condition [0x00007f0f94ccf000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.15-ga/Native Method)
> - parking to wait for <0x00007f1e0178ef68> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.15-ga/LockSupport.java:234)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.15-ga/AbstractQueuedSynchronizer.java:2123)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.15-ga/ScheduledThreadPoolExecutor.java:1182)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.15-ga/ScheduledThreadPoolExecutor.java:899)
> at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.15-ga/ThreadPoolExecutor.java:1054)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.15-ga/ThreadPoolExecutor.java:1114)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.15-ga/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.15-ga/Thread.java:829) {code}
> I found the problem is The following code, we should better give a maxsize for the ScheduledThreadPoolExecutor
>
> !image-2022-06-29-09-37-07-089.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)