Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HPCC-32931 Capture and report execute timings for splitters #19262

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

HPCC-32931 Capture and report execute timings for splitters #19262

wants to merge 2 commits into from

Conversation

shamser
Copy link
Contributor

@shamser shamser commented Nov 1, 2024 •
edited
Loading

Type of change:

  • This change is a bug fix (non-breaking change which fixes an issue).
  • This change is a new feature (non-breaking change which adds functionality).
  • This change improves the code (refactor or other change that does not change the functionality)
  • This change fixes warnings (the fix does not alter the functionality or the generated code)
  • This change is a breaking change (fix or feature that will cause existing behavior to change).
  • This change alters the query API (existing queries will have to be recompiled)

Checklist:

  • My code follows the code style of this project.
    • My code does not create any new warnings from compiler, build system, or lint.
  • The commit message is properly formatted and free of typos.
    • The commit message title makes sense in a changelog, by itself.
    • The commit is signed.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly, or...
    • I have created a JIRA ticket to update the documentation.
    • Any new interfaces or exported functions are appropriately commented.
  • I have read the CONTRIBUTORS document.
  • The change has been fully tested:
    • I have added tests to cover my changes.
    • All new and existing tests passed.
    • I have checked that this change does not introduce memory leaks.
    • I have used Valgrind or similar tools to check for potential issues.
  • I have given due consideration to all of the following potential concerns:
    • Scalability
    • Performance
    • Security
    • Thread-safety
    • Cloud-compatibility
    • Premature optimization
    • Existing deployed queries will not be broken
    • This change fixes the problem, not just the symptom
    • The target branch of this pull request is appropriate for such a change.
  • There are no similar instances of the same problem that should be addressed
    • I have addressed them here
    • I have raised JIRA issues to address them separately
  • This is a user interface / front-end modification
    • I have tested my changes in multiple modern browsers
    • The component(s) render as expected

Smoketest:

  • Send notifications about my Pull Request position in Smoketest queue.
  • Test my draft Pull Request.

Testing:

@shamser shamser requested a review from jakesmith November 1, 2024 16:19
@github-actions GitHub Actions
Copy link

github-actions bot commented Nov 1, 2024

Jira Issue: https://hpccsystems.atlassian.net//browse/HPCC-32931

Jirabot Action Result:
Workflow Transition To: Merge Pending
Updated PR

@shamser shamser changed the title HPCC-32931 Capture and report start timings for splitters HPCC-32931 Capture and report execute timings for splitters Nov 4, 2024
jakesmith
jakesmith reviewed Nov 5, 2024
View reviewed changes
Copy link
Member

@jakesmith jakesmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shamser - please see comments

thorlcr/activities/nsplitter/thnsplitterslave.cpp Outdated
@@ -217,7 +217,10 @@ class NSplitterSlaveActivity : public CSlaveActivity, implements ISharedSmartBuf
assertex(((unsigned)-1) != connectedOutputCount);
activeOutputCount = connectedOutputCount;

PARENT::start();
{
ActivityTimer t(slaveTimerStats, queryTimeActivities());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be more correct if this was after "if (!inputPrepared)" (i.e. included all time in it).
Because this is the total 'start()' time of splitter. It is initiated from the 1st CSplitterOutput::start() to be called.
i.e. if this was a simple act. it would do all this work in start and time it as such.

thorlcr/activities/nsplitter/thnsplitterslave.cpp
@@ -299,6 +302,7 @@ class NSplitterSlaveActivity : public CSlaveActivity, implements ISharedSmartBuf
}
inline const void *nextRow(unsigned outIdx, rowcount_t current)
{
ActivityTimer t(slaveTimerStats, queryTimeActivities());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are the ActivityTimer's in CSplitterOutput::start and CSplitterOutput::nextRow meaningful is anything looking at them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sharedRowStream may block - I think need to time that blocktime and gather it into the activity blocked time,
but can be done separately - can you open another JIRA to come back to this and link to this one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Activities downstream from the splitter arm make use of the CSplitterOutput timings. Downstream activities make use of the queryTotalCycles from the CSplitterOutput (they are not using not NSpitterSlaveActivity::queryTotalCycles).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've created a jira for implementing the blocked time for splitters: https://hpccsystems.atlassian.net/browse/HPCC-32952

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Activities downstream from the splitter arm make use of the CSplitterOutput timings. Downstream activities make use of the queryTotalCycles from the CSplitterOutput (they are not using not NSpitterSlaveActivity::queryTotalCycles).

right, but that means the activity's slaveTimerStats that are being accumulate here, and in prepareInput, aren't going to be used, and prepareInput time will already be counted by the CSplitterOutput::start() that 1st calls it..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The activity's slaveTimerStats is used to report the activity's total time and calculate the activity's local time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, this doesn't really make sense.
The downstream activities, will correctly use the timings from the CSplitterOutput's, as they are the inputs.

But the splitter activity will use these timings from NSplitterSlaveActivity::prepareInput and NSplitterSlaveActivity::nextRow, but that is not representative of how long this splitter activity took.
NB: NSplitterSlaveActivity::nextRow will not be called at all, if using newSplitter, and even when it is, it will be included in the CSplitterOutput::nextRow time (as will the prepareInput time).

How long did the splitter spend processing rows..?
Is it the sum of the time of it's arms (CSplitterOutput's)?
Maybe, that will include the time from the 1st that started the input (prepareInput), and all the time it spent reading off disk in the spilling case, but without accounting for block time, that will also count a lot of blocked time too, e.g. when arm 1 can't return any rows, because arm 2 is behind and blocking.

I don't think slaveTimerStats as a member in the activity, nor accumulating it there is correct.

@shamser shamser requested a review from jakesmith November 7, 2024 09:53
jakesmith
jakesmith reviewed Nov 8, 2024
View reviewed changes
Copy link
Member

@jakesmith jakesmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shamser - see reply re. slaveTimerStats in activity not being used.

@shamser
Copy link
Contributor Author

shamser commented Nov 12, 2024

@shamser - see reply re. slaveTimerStats in activity not being used.

It is used. It is used to report the activity's total time and calculate the activity's local time. (The CSplitterOutput stats are only used by downstream activities). @jakesmith

@shamser shamser requested a review from jakesmith November 12, 2024 12:49
jakesmith
jakesmith reviewed Nov 13, 2024
View reviewed changes
Copy link
Member

@jakesmith jakesmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shamser - see follow up comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jakesmith jakesmith jakesmith left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@shamser @jakesmith