You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Steve Loughran (JIRA)" <ji...@apache.org> on 2016/05/03 10:58:13 UTC

[jira] [Commented] (HADOOP-13065) Add a new interface for retrieving FS and FC Statistics

    [ https://issues.apache.org/jira/browse/HADOOP-13065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268386#comment-15268386 ] 

Steve Loughran commented on HADOOP-13065:
-----------------------------------------

Related to this, I've come across some details about how the reflection-based {{AtomicLongFieldUpdater}} is going to become a lot closer to non-atomic {{volatile long ++}} calls: http://shipilev.net/blog/2015/faster-atomic-fu/

This argues in favour of using this operation for updating metrics directly...it'd mean that the variables could just be simple {{volatile long}}, with a static {{AtomicLongFieldUpdater}} used to update them all

{code}
public final class readMetrics {

private static final AtomicLongFieldUpdater bytesReadUpdater = AtomicLongFieldUpdater.newUpdater(Cell.class, "bytesRead");
private volatile long bytesRead;

public long incBytesRead(long count) {
  return bytesReadUpdater.addAndGet(count);
}
{code}

HBase uses this in {{org.apache.hadoop.hbase.util.Counter}}, where it's described as "High scalable counter. Thread safe."


> Add a new interface for retrieving FS and FC Statistics
> -------------------------------------------------------
>
>                 Key: HADOOP-13065
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13065
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs
>            Reporter: Ram Venkatesh
>            Assignee: Mingliang Liu
>         Attachments: HADOOP-13065-007.patch, HDFS-10175.000.patch, HDFS-10175.001.patch, HDFS-10175.002.patch, HDFS-10175.003.patch, HDFS-10175.004.patch, HDFS-10175.005.patch, HDFS-10175.006.patch, TestStatisticsOverhead.java
>
>
> Currently FileSystem.Statistics exposes the following statistics:
> BytesRead
> BytesWritten
> ReadOps
> LargeReadOps
> WriteOps
> These are in-turn exposed as job counters by MapReduce and other frameworks. There is logic within DfsClient to map operations to these counters that can be confusing, for instance, mkdirs counts as a writeOp.
> Proposed enhancement:
> Add a statistic for each DfsClient operation including create, append, createSymlink, delete, exists, mkdirs, rename and expose them as new properties on the Statistics object. The operation-specific counters can be used for analyzing the load imposed by a particular job on HDFS. 
> For example, we can use them to identify jobs that end up creating a large number of files.
> Once this information is available in the Statistics object, the app frameworks like MapReduce can expose them as additional counters to be aggregated and recorded as part of job summary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org