[
https://issues.apache.org/jira/browse/HBASE-30320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104249#comment-18104249
]
Hudson commented on HBASE-30320:
--------------------------------
Results for branch branch-3.0
[build #11 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3.0/11/]:
(x) *{color:red}-1 overall{color}*
----
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3.0/11/General_20Nightly_20Build_20Report/]
(x) {color:red}-1 jdk17 hadoop3 checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3.0/11/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
> 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)
