Hi,
Is it happening regularly? kind of with regular FBR's, in that case you
need to configure your Datanode's block report interval high enough and in
a way that all of them don't bombard the namenode at same time and there is
enough gap between FBR's from the datanodes.
If it is happening with First FBR itself, give a check to the config:
dfs.blockreport.initialDelay it can be used to prevent all datanodes from
shooting requests to the namenode with block reports at the same time.
Long back I had a proposal to optimize or maybe get rid of the FBR's itself
in cases where it wasn't required,we tried a POC and if I remember it was
working, but I never got a chance to contribute it back or explore more
around the challenges. The ML proposal[1] and the Jira stays at[2]
There is a jira chasing to improve the lock time as well in case of FBR[3],
that too isn't merged yet. If you want to explore more, you can get some
stuff at [4], it points to two Jira's as well, give a check if they can
help, if you already don't have them.
-Ayush
[1] https://lists.apache.org/thread/8poctzcmcxk7jmyj8vyb5txwdv6t57lc
[2] https://issues.apache.org/jira/browse/HDFS-15162
[3] https://issues.apache.org/jira/browse/HDFS-14657
[4] https://issues.apache.org/jira/browse/HDFS-14186
On Thu, 1 Dec 2022 at 12:34, 尉雁磊 wrote:
> hi ，In a cluster of thousands of Datanodes, the Capacity of each datanode
> is not exactly the same. In this case, Datanodes with a large Capacity
> have more blocks and report more blocks to FBR, which takes longer to
> process FBR. FBR processing is done in a queue (
> dfs.namenode.blockreport.queue.size). If FBR takes a long time to
> process, FBRIBRQUEUQE will pile up. Obviously, as more data is added,
> FbribrQueuQE will pile up more frequently, affecting namenode performance.
> Is this a problem or is there any optimization method？
>
