Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 22 Sep 2017 22:00:05 +0000 (UTC)
From: "Erik Krogen (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13104418.1506117279000.180726.1506117605242@Atlassian.JIRA>
In-Reply-To: <JIRA.13104418.1506117279000@Atlassian.JIRA>
References: <JIRA.13104418.1506117279000@Atlassian.JIRA> <JIRA.13104418.1506117279992@jira-lw-us.apache.org>
Subject: [jira] [Updated] (HDFS-12533) NNThroughputBenchmark threads get
 stuck on UGI.getCurrentUser()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 22 Sep 2017 22:00:10 -0000


     [ https://issues.apache.org/jira/browse/HDFS-12533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erik Krogen updated HDFS-12533:
-------------------------------
    Description: 
In {{NameNode#getRemoteUser()}}, it first attempts to fetch from the RPC user (not a synchronized operation), and if there is no RPC call, it will call {{UserGroupInformation#getCurrentUser()}} (which is {{synchronized}}). This makes it efficient for RPC operations (the bulk) so that there is not too much contention.

In NNThroughputBenchmark, however, there is no RPC call since we bypass that later, so with a high thread count many of the threads are getting stuck. At one point I attached a profiler and found that quite a few threads had been waiting for {{#getCurrentUser()}} for 2 minutes ( ! ). When taking this away I found some improvement in the throughput numbers I was seeing. To more closely emulate a real NN we should improve this issue.

  was:
In {{NameNode#getRemoteUser()}}, it first attempts to fetch from the RPC user (not a synchronized operation), and if there is no RPC call, it will call {{UserGroupInformation#getCurrentUser()}} (which is {{synchronized}}). This makes it efficient for RPC operations (the bulk) so that there is not too much contention.

In NNThroughputBenchmark, however, there is no RPC call since we bypass that later, so with a high thread count many of the threads are getting stuck. At one point I attached a profiler and found that quite a few threads had been waiting for {{#getCurrentUser()}} for 2 minutes (!). When taking this away I found some improvement in the throughput numbers I was seeing. To more closely emulate a real NN we should improve this issue.


> NNThroughputBenchmark threads get stuck on UGI.getCurrentUser()
> ---------------------------------------------------------------
>
>                 Key: HDFS-12533
>                 URL: https://issues.apache.org/jira/browse/HDFS-12533
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Erik Krogen
>
> In {{NameNode#getRemoteUser()}}, it first attempts to fetch from the RPC user (not a synchronized operation), and if there is no RPC call, it will call {{UserGroupInformation#getCurrentUser()}} (which is {{synchronized}}). This makes it efficient for RPC operations (the bulk) so that there is not too much contention.
> In NNThroughputBenchmark, however, there is no RPC call since we bypass that later, so with a high thread count many of the threads are getting stuck. At one point I attached a profiler and found that quite a few threads had been waiting for {{#getCurrentUser()}} for 2 minutes ( ! ). When taking this away I found some improvement in the throughput numbers I was seeing. To more closely emulate a real NN we should improve this issue.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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