[
https://issues.apache.org/jira/browse/HDFS-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298099#comment-16298099
]
Zhe Zhang edited comment on HDFS-12943 at 12/20/17 8:54 AM:
------------------------------------------------------------
Thanks [~csun], interesting results! You used only 1 SBN to server reads right?
In both configurations (with and without stale reads), I assume you were
saturating the system? It's interesting to see that with two NNs serving RPCs
(1 ANN + 1 SBN), the throughput actually more than doubled the throughput with
1 ANN. Did you use Namesystem unfair locking?
If I understand correctly, both your test and the Dynamometer test are more
like trace-driven micro benchmarks, where a container issues a certain type of
RPC at given timestamp. Chris was probably referring to a test job with "real
code" like {{if !file_exists(path) then create_file(path)}}, where the blocking
relationship between calls are miniced.
[~chris.douglas]: the "natural" increase of write traffic is an interesting
question. I don't think the feature will increase the total amount of write
RPCs (a given job will still issue that many writes overall). Writes within a
job could become more bursty but the job itself will run for shorter.
Statistically, the 1000s of jobs on the cluster would probably smooth out this
increased burstiness.
was (Author: zhz):
Thanks [~csun], interesting results! You used only 1 SBN to server reads right?
In both configurations (with and without stale reads), I assume you were
saturating the system right? It's interesting to see that with two NNs serving
RPCs (1 ANN + 1 SBN), the throughput actually more than doubled the throughput
with 1 ANN. Did you use Namesystem unfair locking?
If I understand correctly, both your test and the Dynamometer test are more
like trace-driven micro benchmarks, where a container issues a certain type of
RPC at given timestamp. Chris was probably referring to a test job with "real
code" like {{if !file_exists(path) then create_file(path)}}, where the blocking
relationship between calls are miniced.
[~chris.douglas]: the "natural" increase of write traffic is an interesting
question. I don't think the feature will increase the total amount of write
RPCs (a given job will still issue that many writes overall). Writes within a
job could become more bursty but the job itself will run for shorter.
Statistically, the 1000s of jobs on the cluster would probably smooth out this
increased burstiness.
> Consistent Reads from Standby Node
> ----------------------------------
>
> Key: HDFS-12943
> URL: https://issues.apache.org/jira/browse/HDFS-12943
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: hdfs
> Reporter: Konstantin Shvachko
> Attachments: ConsistentReadsFromStandbyNode.pdf
>
>
> StandbyNode in HDFS is a replica of the active NameNode. The states of the
> NameNodes are coordinated via the journal. It is natural to consider
> StandbyNode as a read-only replica. As with any replicated distributed system
> the problem of stale reads should be resolved. Our main goal is to provide
> reads from standby in a consistent way in order to enable a wide range of
> existing applications running on top of HDFS.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
