[
https://issues.apache.org/jira/browse/HDFS-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096107#comment-16096107
]
photogamerun commented on HDFS-7964:
------------------------------------
I found
if editPendingQ in FSEditLogAsync.java blocked, all the IPC handlers will slow
down and performance degraded.
so when I backport the code to 2.5.0-cdh5.3.2 I did some change in logEdit
method
void logEdit(final FSEditLogOp op) {
Server.Call rpcCall = Server.getCurCall().get();
if (rpcCall != null) {
if (editPendingQ.size() > 32768) {
super.logEdit(op);
}
enqueueEdit(op);
} else {
super.logEdit(op);
}
}
> Add support for async edit logging
> ----------------------------------
>
> Key: HDFS-7964
> URL: https://issues.apache.org/jira/browse/HDFS-7964
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Affects Versions: 2.0.2-alpha
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Fix For: 2.8.0, 2.9.0, 3.0.0-alpha1
>
> Attachments: HDFS-7964-branch-2.7.patch,
> HDFS-7964-branch-2.8.0.patch, HDFS-7964.patch, HDFS-7964.patch,
> HDFS-7964.patch, HDFS-7964.patch, HDFS-7964-rebase.patch
>
>
> Edit logging is a major source of contention within the NN. LogEdit is
> called within the namespace write log, while logSync is called outside of the
> lock to allow greater concurrency. The handler thread remains busy until
> logSync returns to provide the client with a durability guarantee for the
> response.
> Write heavy RPC load and/or slow IO causes handlers to stall in logSync.
> Although the write lock is not held, readers are limited/starved and the call
> queue fills. Combining an edit log thread with postponed RPC responses from
> HADOOP-10300 will provide the same durability guarantee but immediately free
> up the handlers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
