[
https://issues.apache.org/jira/browse/HDDS-17591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajesh updated HDDS-17591:
--------------------------
Description:
Parent task: HDDS-17586.
Some OM spans are leaves. They take most of a large parent and have no
children, so the trace still does not show which step inside them was slow. A
parent of about 100ms with two children of about 1ms is the same kind of gap
when the rest of the time sits in one unnamed block.
Walk the leaf spans on the write and read paths. When one leaf is most of a
large parent, split out the slow step:
* {{OM.validateAndUpdateCache}}, when it is much larger than the {{DB}} spans
for that request.
* {{OM.key.generateEDEK}} and {{OM.kms.getBucketEncryptionKey}}.
* {{OM.bucket.isBucketEmpty}}, {{OM.bucket.checkIncompleteMPUs}} and
{{OM.bucket.checkSnapshots}}.
* {{OM.snapshot.createCheckpoint}}.
* Lock wait, when it is a large part of {{OM.preExecute}} or
{{OM.validateAndUpdateCache}} and is not already its own span.
A leaf of about 1ms stays as it is. Split a leaf only when the parent is large
and this leaf is where that time went.
was:
Some OM work doesn't go through an interface that can be proxied: static
helpers, code that runs on another thread, and code inside a single large
method. Add explicit spans for it:
* \{{OM.startTransaction}}, \{{OM.applyTransaction}} and \{{OM.query}} in
\{{OzoneManagerStateMachine}}. The OM span's trace ID is carried in the
\{{OMRequest}}, so the apply on the executor thread stays in the same trace.
* Critical static paths, for example OM lock acquisition and the double-buffer
flush. Confirm the final list against latency hot spots.
* Exceptions recorded on these spans with \{{TracingUtil.recordException}}.
Summary: Split large OM leaf spans that hide where the time goes (was:
Add logical spans for OM paths not covered by the proxies)
> Split large OM leaf spans that hide where the time goes
> -------------------------------------------------------
>
> Key: HDDS-17591
> URL: https://issues.apache.org/jira/browse/HDDS-17591
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: rajesh
> Assignee: rajesh
> Priority: Major
>
> Parent task: HDDS-17586.
> Some OM spans are leaves. They take most of a large parent and have no
> children, so the trace still does not show which step inside them was slow. A
> parent of about 100ms with two children of about 1ms is the same kind of gap
> when the rest of the time sits in one unnamed block.
> Walk the leaf spans on the write and read paths. When one leaf is most of a
> large parent, split out the slow step:
> * {{OM.validateAndUpdateCache}}, when it is much larger than the {{DB}} spans
> for that request.
> * {{OM.key.generateEDEK}} and {{OM.kms.getBucketEncryptionKey}}.
> * {{OM.bucket.isBucketEmpty}}, {{OM.bucket.checkIncompleteMPUs}} and
> {{OM.bucket.checkSnapshots}}.
> * {{OM.snapshot.createCheckpoint}}.
> * Lock wait, when it is a large part of {{OM.preExecute}} or
> {{OM.validateAndUpdateCache}} and is not already its own span.
> A leaf of about 1ms stays as it is. Split a leaf only when the parent is
> large and this leaf is where that time went.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
