[
https://issues.apache.org/jira/browse/HBASE-30320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104202#comment-18104202
]
Hudson commented on HBASE-30320:
--------------------------------
Results for branch branch-3.0
[build #14 on
builds.a.o|https://ci-hbase.apache.org/job/HBase-Integration-Test/job/branch-3.0/14/]:
(/) *{color:green}+1 overall{color}*
----
details (if available):
(/) {color:green}+1 client integration test for 3.3.5 {color}
(/) {color:green}+1 client integration test for 3.3.5 with shaded hadoop
client{color}
(/) {color:green}+1 client integration test for 3.3.6 {color}
(/) {color:green}+1 client integration test for 3.3.6 with shaded hadoop
client{color}
(/) {color:green}+1 client integration test for 3.4.0 {color}
(/) {color:green}+1 client integration test for 3.4.0 with shaded hadoop
client{color}
(/) {color:green}+1 client integration test for 3.4.1 {color}
(/) {color:green}+1 client integration test for 3.4.1 with shaded hadoop
client{color}
(/) {color:green}+1 client integration test for 3.4.2 {color}
(/) {color:green}+1 client integration test for 3.4.2 with shaded hadoop
client{color}
(/) {color:green}+1 client integration test for 3.4.3 {color}
(/) {color:green}+1 client integration test for 3.4.3 with shaded hadoop
client{color}
> TestMemStoreLAB#testLABChunkQueue OOM on fast hardware due to unbounded
> off-pool chunk allocation
> -------------------------------------------------------------------------------------------------
>
> Key: HBASE-30320
> URL: https://issues.apache.org/jira/browse/HBASE-30320
> Project: HBase
> Issue Type: Bug
> Components: test
> Affects Versions: 2.5.16, 2.6.7
> Reporter: Umesh Kumar Kumawat
> Assignee: Umesh Kumar Kumawat
> Priority: Minor
> Labels: pull-request-available
> Fix For: 4.0.0-alpha-1, 2.7.0, 3.1.0, 3.0.1
>
>
> The test spawns 10 threads that allocate 256KB chunks in a tight loop for a
> fixed 1-second window (Thread.sleep(1000)). Once the ChunkCreator pool
> reaches its maxCount, subsequent allocations fall through
> to unbounded off-pool chunk creation (ChunkCreator#createChunk). All chunks
> remain live in mslab.chunks until mslab.close() is called after the threads
> stop.
> On fast hardware (Apple Silicon, high memory bandwidth), threads complete
> ~5,000 iterations/thread/sec, creating ~50,000 chunks (~12.5GB) in that
> 1-second window. On slower x86 CI machines, the same
> window produces only ~700 iterations/thread/sec (~1.7GB), fitting within
> the default 2.2GB surefire heap.
> The test's memory consumption is non-deterministic — it depends on
> CPU/memory speed rather than a fixed workload.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)