[
https://issues.apache.org/jira/browse/HDFS-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524156#comment-16524156
]
stack commented on HDFS-13702:
------------------------------
bq. ....what do you think?
I think we need to be able to trace end-to-end where time is being spent.
I think that if htrace is not enabled, it should not add friction.
I think harley-davidson's are awful motorcycles but even they don't deserve the
abuse they are getting.
I think those numbers you posted for the difference your patch makes in
throughput stripping htrace are radical.
Poor htrace has been added to the apache attic. It got no loving.
htace in hdfs got no loving either post inital-commit; it was added and then
let fester.
I think we should commit this patch, +1, and then we can file another to
review how to move forward with tracing in light of recent developments in
htrace project; i.e. purge all other htrace references, look into alternatives,
etc.
> HTrace hooks taking 10-15% CPU in DFS client when disabled
> ----------------------------------------------------------
>
> Key: HDFS-13702
> URL: https://issues.apache.org/jira/browse/HDFS-13702
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: performance
> Affects Versions: 3.0.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Major
> Attachments: hdfs-13702.patch, hdfs-13702.patch
>
>
> I am seeing DFSClient.newReaderTraceScope take ~15% CPU in a teravalidate
> workload even when HTrace is disabled. This is because it stringifies several
> integers. We should avoid all allocation and stringification when htrace is
> disabled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
