[ https://issues.apache.org/jira/browse/AMBARI-20392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905130#comment-15905130 ]
Hadoop QA commented on AMBARI-20392: ------------------------------------ {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12857320/AggregateMetric.patch against trunk revision . {color:red}-1 patch{color}. The patch command could not apply the patch. Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/10967//console This message is automatically generated. > Get aggregate metric records from HBase encounters performance issues > --------------------------------------------------------------------- > > Key: AMBARI-20392 > URL: https://issues.apache.org/jira/browse/AMBARI-20392 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics > Affects Versions: 2.4.2 > Reporter: Chuan Jin > Attachments: AggregateMetric.patch > > > I have a mini cluster ( ~6 nodes) managed by Ambari, and use a distributed > HBase (~3 nodes) to hold metrics collected from these nodes. After I deploy > YARN serivce, then I notice that some widgets (Cluster Memory,Cluster > Disk,...) cannot display properly in the YARN service dashboard page. And > Ambari Server has continuous timeout exceptions, which complains that it > doesn't get timeline metrics for connection refused. > The request timeout parameter is 5s, which means the query of getting metrics > from HBase takes more time than that. Then I use Phoenix shell to login and > perform the same query in the HBase , and it takes nearly 30s to finish. But > If I split the big query into small pieces , i mean, use less values in the > "metric_name" field in the where ... in clause , then the result return in 1s > after several small queries. > The query performance in HBase is highly based on the design of rowkey and > the proper usage for it. In the method of getting aggregate metrics, AMS > collector query the METRIC_AGGREGATE table in a way that may cause the > co-processor to scan several regions across different RS. If we add more > metrics in the service dashboard, this situation will be worse. -- This message was sent by Atlassian JIRA (v6.3.15#6346)