-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-29068: Report percentFilesLocalPrimaryRegions metric #6596
base: master
Are you sure you want to change the base?
HBASE-29068: Report percentFilesLocalPrimaryRegions metric #6596
Conversation
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll wait for tests to pass for final approval, but this looks good to me
"The percent of HFiles used by secondary regions that are stored on the local hdfs data node."; | ||
"The percent of HFiles used by secondary regions that are stored on the local hdfs data node. " | ||
+ "This is not likely to reach 100%"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed it's unlikely, but wouldn't it be possible to achieve 100% locality for both primary and secondary replicas if your number of replicas is less than or equal to your hdfs replication factor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically that's possible. I say it's unlikely because something would need to ensure that all the block replicas for a secondary region end up co-located with the region, and nothing I'm aware of would do that. Compactions won't help. Internally at hubspot we have the locality healer, but today even that doesn't know about secondary regions, although I plan on that eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The balancer is aware of locality — I wonder to what extent LocalityBasedCandidateGenerator could maintain secondary replica locality. I haven't looked at the implementation with replicas in mind, but it might already balance secondary replicas based on locality to some extent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. I would still argue that that isn't likely to be very helpful. The region balancer needs to put a region on exactly one server, but in the absence of some helpful force, it's unlikely that all the blocks for any given region exist on a single DataNode. The region balancer can only do as well as the random block distribution allows. Before we had the locality healer at hubspot, we experienced this difficultly all the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good point
💔 -1 overall
This message was automatically generated. |
Test failure appears unrelated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can ship this tomorrow
@rmdmattingly reminder about this, when you have a chance |
If you are running a table with region replicas, the secondary replicas usually cannot achieve 100% locality. Currently a RegionServer reports two locality metrics:
percentFilesLocal
percentFilesLocalSecondaryRegions
Both of these will be less than 100% if region replicas are enabled. The best we can do is get 100% locality for the primary replicas, but there is currently no way to see if we've achieved it.
I propose introducing the new metric
percentFilesLocalPrimaryRegions
, which will close this gap.