You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Erik Krogen (JIRA)" <ji...@apache.org> on 2019/04/01 15:48:00 UTC

[jira] [Commented] (HDFS-14370) Edit log tailing fast-path should allow for backoff

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

Erik Krogen commented on HDFS-14370:
------------------------------------

Copying [~starphin]'s comment from HDFS-14276:
{quote}
Maybe we can just sleep 10ms in rpc server side if there are no edit logs. As a consequence that rpc thread will be blocked for 10ms.
{quote}
I think by "server side" you're referring to the JournalNode. I think I would prefer to keep the sleep on the NN side, to avoid handler threads being tied up on the JN. This is similar to how the NN, when it wants a client to backoff due to load, throws a backoff exception and expects the client to act accordingly.

> Edit log tailing fast-path should allow for backoff
> ---------------------------------------------------
>
>                 Key: HDFS-14370
>                 URL: https://issues.apache.org/jira/browse/HDFS-14370
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode, qjm
>    Affects Versions: 3.3.0
>            Reporter: Erik Krogen
>            Assignee: Erik Krogen
>            Priority: Major
>
> As part of HDFS-13150, in-progress edit log tailing was changed to use an RPC-based mechanism, thus allowing the edit log tailing frequency to be turned way down, and allowing standby/observer NameNodes to be only a few milliseconds stale as compared to the Active NameNode.
> When there is a high volume of transactions on the system, each RPC fetches transactions and takes some time to process them, self-rate-limiting how frequently an RPC is submitted. In a lightly loaded cluster, however, most of these RPCs return an empty set of transactions, consuming a high (de)serialization overhead for very little benefit. This was reported by [~jojochuang] in HDFS-14276 and I have also seen it on a test cluster where the SbNN was submitting 8000 RPCs per second that returned empty.
> I propose we add some sort of backoff to the tailing, so that if an empty response is received, it will wait a longer period of time before submitting a new RPC.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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