[ https://issues.apache.org/jira/browse/HDFS-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223437#comment-14223437 ]
Daryn Sharp commented on HDFS-7435: ----------------------------------- We've also seen large block reports aggravate GC, not due to decoded size, but due to the spew of garbage from the re-allocs and (un)boxing. This patch is basically taking us back to pre-PB performance & behavior. The block report is ~44,000 blocks/MB which at our scale is a few megs per report. HDFS-4879 chunked a list of blocks to delete because of 25M entries consuming ~400MB. I don't foresee blocks/node approaching that level anytime soon. In that light, it's probably premature to introduce chunking? > PB encoding of block reports is very inefficient > ------------------------------------------------ > > Key: HDFS-7435 > URL: https://issues.apache.org/jira/browse/HDFS-7435 > Project: Hadoop HDFS > Issue Type: Improvement > Components: datanode, namenode > Affects Versions: 2.0.0-alpha, 3.0.0 > Reporter: Daryn Sharp > Assignee: Daryn Sharp > Priority: Critical > Attachments: HDFS-7435.patch > > > Block reports are encoded as a PB repeating long. Repeating fields use an > {{ArrayList}} with default capacity of 10. A block report containing tens or > hundreds of thousand of longs (3 for each replica) is extremely expensive > since the {{ArrayList}} must realloc many times. Also, decoding repeating > fields will box the primitive longs which must then be unboxed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)