Chu Cheng Li created HDDS-16669:
-----------------------------------
Summary: [Ozone Local] Investigate heap and memory overhead under
lightweight S3 workloads
Key: HDDS-16669
URL: https://issues.apache.org/jira/browse/HDDS-16669
Project: Apache Ozone
Issue Type: Sub-task
Reporter: Chu Cheng Li
Attachments: kuberay-history-server-resource-comparison.png
Following the [Slack
discussion|https://opensource4you.slack.com/archives/C07PLV9QNLF/p1790868752976099?thread_ts=1790686067.612819&cid=C07PLV9QNLF],
investigate where memory is used in the single-JVM Ozone implementation under
HDDS-14893. The KubeRay History Server S3/e2e workload provides a
small-workload example, although this is not Ozone's primary optimization
scenario.
h3. Baseline
The same TestCollector + TestHistoryServer workload at KubeRay commit
888e6145ab863cc4a23a5a0d9d1ceb9fa27c7f9b was run three times per backend,
sequentially in rotated order, with an 8-CPU/8-GiB limit per store. All 12
formal runs passed the main cases; the same upstream nested PID check was
skipped in every run.
||Backend||Mean working set (MiB)||Mean RSS (MiB)||Mean CPU (cores)||Mean e2e
(min)||
|Single-JVM Ozone prototype|626|601|0.280|29.64|
|Ozone 2.1.2 all-in-one (four JVMs)|1272|1238|0.302|29.35|
|RustFS 1.0.0|243|221|0.022|29.32|
|SeaweedFS 4.48|285|269|0.020|29.24|
These are container working-set/RSS measurements, *not Java heap measurements*.
Summaries cover the timed e2e window, excluding backend setup/readiness and the
idle baseline. This is a functional workload with three repetitions, not a
throughput or scalability benchmark.
The prototype is the historical 2.2.0-SNAPSHOT implementation from
[peterxcli/ozone PR #13|https://github.com/peterxcli/ozone/pull/13] at
8f12228177907df2a6d979b1d0e90911b4814397: SCM, OM, DataNode and S3G in one JVM,
512-MiB maximum heap, standalone/one replica. The all-in-one comparator uses
the original KubeRay configuration with four JVMs at 128 MiB each. Version and
replication/configuration differences prevent attributing the observed
difference solely to JVM consolidation.
h3. Investigation
* Profile startup, idle and e2e phases, recording heap used/committed/max
separately from RSS and container working set.
* Identify the largest retained heap consumers and quantify native/off-heap
contributors where possible, including RocksDB, direct buffers and caches.
* Document the reproduction configuration, profiling procedure and findings;
identify actionable follow-up optimizations.
* Validate proposed changes against the same functional suite and report
memory/runtime tradeoffs.
The resource comparison chart accompanies this baseline. Its traces show one
observed median-duration repetition per backend; the summary above averages all
three repetitions. CPU and memory cover store processes; pod network includes
the common client and excludes loopback. Per-store disk I/O was unavailable in
the rootless environment.
This task tracks investigation and follow-up opportunities; it does not set a
numerical reduction target or release deadline.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
