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

Andrew Wang commented on HDFS-6982:
-----------------------------------

How would this behave to a sudden, large spike in operations? This is the 
situation we're trying to detect. i.e. for something like:

{noformat}
0, 0, 0, 1000000, 0, 0, 0, ...
{noformat}

What I'd want to see is essentially a step function going 0 -> 1000000 -> 0, 
but an EWMA would necessarily tail off exponentially.

I'm also happy to take a look at any references you have. I've done some 
reading on calculating percentiles on rolling windows, and what we have now is 
pretty typical for that, i.e. a number of buckets each representing a fixed 
time interval, aggregating buckets to calculate the metric, old buckets being 
discarded as time passes.

> nntop: top­-like tool for name node users
> -----------------------------------------
>
>                 Key: HDFS-6982
>                 URL: https://issues.apache.org/jira/browse/HDFS-6982
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>            Reporter: Maysam Yabandeh
>            Assignee: Maysam Yabandeh
>         Attachments: HDFS-6982.patch, HDFS-6982.v2.patch, HDFS-6982.v3.patch, 
> HDFS-6982.v4.patch, HDFS-6982.v5.patch, HDFS-6982.v6.patch, 
> nntop-design-v1.pdf
>
>
> In this jira we motivate the need for nntop, a tool that, similarly to what 
> top does in Linux, gives the list of top users of the HDFS name node and 
> gives insight about which users are sending majority of each traffic type to 
> the name node. This information turns out to be the most critical when the 
> name node is under pressure and the HDFS admin needs to know which user is 
> hammering the name node and with what kind of requests. Here we present the 
> design of nntop which has been in production at Twitter in the past 10 
> months. nntop proved to have low cpu overhead (< 2% in a cluster of 4K 
> nodes), low memory footprint (less than a few MB), and quite efficient for 
> the write path (only two hash lookup for updating a metric).



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

Reply via email to