[
https://issues.apache.org/jira/browse/PHOENIX-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14603653#comment-14603653
]
Samarth Jain commented on PHOENIX-1819:
---------------------------------------
If auto-commit was on for the connection, then the finalState is an empty
mutation state. However, the empty mutation state could have mutation metrics
within it. By joining the connection's mutation state with the empty mutation
state, we are able to combine the mutation metrics. So yes, the change is
essentially for the fact that we don't want to lose metrics collected during
parallel execution. I will add a comment. Thanks for reviewing [~jamestaylor].
{code}
+ if (clonedConnection.getAutoCommit()) {
+ clonedConnection.getMutationState().join(state);
+ clonedConnection.commit();
+ ConnectionQueryServices services =
clonedConnection.getQueryServices();
+ int maxSize =
services.getProps().getInt(QueryServices.MAX_MUTATION_SIZE_ATTRIB,
QueryServicesOptions.DEFAULT_MAX_MUTATION_SIZE);
+ /*
+ * Everything that was mutated as part of the clonedConnection has
been committed. However, we want to
+ * report the mutation work done using this clonedConnection as
part of the overall mutation work of the
+ * parent connection. So we need to set those metrics in the empty
mutation state so that they could be
+ * combined with the parent connection's mutation metrics (as part
of combining mutation state) in the
+ * close() method of the iterator being returned. Don't combine
the read metrics in parent context yet
+ * though because they are possibly being concurrently modified by
other threads at this stage. Instead we
+ * will get hold of the read metrics when all the mutating
iterators are done.
+ */
+ state = MutationState.emptyMutationState(maxSize,
clonedConnection);
+
state.getMutationMetricQueue().combineMetricQueues(clonedConnection.getMutationState().getMutationMetricQueue());
}
{code}
> Report resource consumption per phoenix statement
> -------------------------------------------------
>
> Key: PHOENIX-1819
> URL: https://issues.apache.org/jira/browse/PHOENIX-1819
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Samarth Jain
> Assignee: Samarth Jain
> Fix For: 5.0.0, 4.4.1
>
> Attachments: PHOENIX-1819-rebased.patch, PHOENIX-1819.patch,
> PHOENIX-1819_v2.patch
>
>
> In order to get insight into what phoenix is doing and how much it is doing
> per request, it would be ideal to get a single log line per phoenix request.
> The log line could contain request level metrics like:
> 1) Number of spool files created.
> 2) Number of parallel scans.
> 3) Number of serial scans.
> 4) Query failed - boolean
> 5) Query time out - boolean
> 6) Query time.
> 7) Mutation time.
> 8) Mutation size in bytes.
> 9) Number of mutations.
> 10) Bytes allocated by the memory manager.
> 11) Time spent by threads waiting for the memory to be allocated.
> 12) Number of tasks submitted to the pool.
> 13) Number of tasks rejected.
> 14) Time spent by tasks in the queue.
> 15) Time taken by tasks to complete - from construction to execution
> completion.
> 16) Time taken by tasks to execute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
