[
https://issues.apache.org/jira/browse/PHOENIX-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14603492#comment-14603492
]
James Taylor commented on PHOENIX-1819:
---------------------------------------
+1. Outstanding work, [~samarthjain]. One question, is this change so that the
metrics aren't lost during parallel execution? Any other implications? I just
want to make sure the same change (which is committed on the server), isn't
being committed again and sent back over the server. Maybe a comment if you
think that'll help.
{code}
byte[] value = PLong.INSTANCE.toBytes(totalRowCount);
KeyValue keyValue = KeyValueUtil.newKeyValue(UNGROUPED_AGG_ROW_KEY,
SINGLE_COLUMN_FAMILY, SINGLE_COLUMN, AGG_TIMESTAMP, value, 0, value.length);
final Tuple tuple = new SingleKeyValueTuple(keyValue);
@@ -92,11 +105,9 @@ public abstract class MutatingParallelIteratorFactory
implements ParallelIterato
try {
// Join the child mutation states in close, since this is
called in a single threaded manner
// after the parallel results have been processed.
- if (!connection.getAutoCommit()) {
-
MutatingParallelIteratorFactory.this.connection.getMutationState().join(finalState);
- }
+
MutatingParallelIteratorFactory.this.connection.getMutationState().join(finalState);
} finally {
- connection.close();
+ clonedConnection.close();
}
{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)
