devmadhuu commented on code in PR #11181:
URL: https://github.com/apache/ozone/pull/11181#discussion_r3916513674
##########
hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/tasks/MultipartInfoInsightHandler.java:
##########
@@ -228,6 +239,60 @@ private void applyLegacyPartSizes(OmMultipartKeyInfo
multipartKeyInfo, String ta
});
}
+ /**
+ * Adds (or subtracts) the sizes of a split-schema MPU's parts from the size
maps by querying
+ * the multipartPartsTable. For legacy-schema MPUs, this method does nothing
(their parts are
+ * embedded and handled by applyLegacyPartSizes).
+ *
+ * @param multipartKeyInfo The MPU metadata.
+ * @param multipartKey The MPU key (used to extract uploadId).
+ * @param tableName The table name.
+ * @param unReplicatedSizeMap Map to update with unreplicated sizes.
+ * @param replicatedSizeMap Map to update with replicated sizes.
+ * @param add {@code true} to add sizes, {@code false} to subtract.
+ * @param omMetadataManager OM metadata manager for accessing
multipartPartsTable.
+ */
+ private void applySplitSchemaPartSizes(OmMultipartKeyInfo multipartKeyInfo,
String multipartKey, String tableName,
Review Comment:
This adds a lot of work to the event path for no benefit. In split schema,
every part commit rewrites the `multipartInfoTable` row, which Recon sees as an
`UPDATE`. Each `UPDATE` now opens two RocksDB iterators over
`multipartPartsTable` and scans all parts committed so far for that upload
(once for the subtract pass, once for the add pass), deserializing each
`OmMultipartPartInfo`.
Since parts arrive incrementally, commit #k scans ~2k rows, so a single MPU
with N parts does about N² part-row reads over its lifetime. S3 allows up to
10,000 parts, so one big upload is on the order of 100M reads — and this runs
on the same thread that keeps Recon in sync with OM, so it directly increases
Recon lag. Concurrent uploads multiply it.
And as noted in the correctness comment, the two passes cancel to zero, so
this is effectively pure overhead. Moving accounting to `multipartPartsTable`
events would make it O(1) per part instead of O(parts²) per MPU.
##########
hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/tasks/MultipartInfoInsightHandler.java:
##########
@@ -114,7 +120,8 @@ public void handleDeleteEvent(OMDBUpdateEvent<String,
Object> event, String tabl
*/
@Override
public void handleUpdateEvent(OMDBUpdateEvent<String, Object> event, String
tableName,
Review Comment:
I don't think this actually fixes split-schema sizes via events, and in some
cases it makes the numbers worse than before.
The problem is that `applySplitSchemaPartSizes` reads the live
`multipartPartsTable`, but Recon commits the WAL batch to its own RocksDB
before process() runs. So by the time these handlers execute:
On `UPDATE` (every part commit): we call `applySplitSchemaPartSizes` once to
subtract the old value and once to add the new value, but both calls scan the
same live parts table for the same `uploadId` with the same replication config.
They cancel to exactly zero, so part commits never accumulate any size.
On `DELETE` (complete/abort): the part rows are deleted in the same batch as
the `multipartInfoTable` row, so the scan finds nothing and subtracts 0.
On PUT (initiate): normally there are no parts yet, so it adds 0 — but if
initiate + commits land in the same Recon sync, PUT sees the already-committed
parts and adds the full size. Since DELETE later subtracts 0, that size stays
in the counter forever until the next reprocess.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
