[
https://issues.apache.org/jira/browse/HBASE-22686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16884181#comment-16884181
]
David Manning commented on HBASE-22686:
---------------------------------------
No objections. I also feel that it won't drastically change anything when
determining whether to pick up 1 or 2 tasks, with default settings.
{quote}However, the regionserver side coordination logic -
ZkSplitLogWorkerCoordination - only allows a regionserver to grab one task one
at a time. That upper limit will be the number of currently live regionservers.
{quote}
I was only commenting that the system should take more than 1 task per RS if
there are more tasks than regionservers, so the upper limit isn't strictly the
number of live servers. Thus, I can understand why the original logic may have
tried to optimize for only taking 1 per RS in the case where number of tasks
are significantly smaller than available servers. This is probably the most
common case as all servers work to recover the few servers which died. Perhaps
multiWAL changes this equation?
But it also seems reasonable to let each RS just try to do its maximum
allowable work, so no objection.
> ZkSplitLogWorkerCoordination doesn't allow a regionserver to pick up all of
> the split work it is capable of
> -----------------------------------------------------------------------------------------------------------
>
> Key: HBASE-22686
> URL: https://issues.apache.org/jira/browse/HBASE-22686
> Project: HBase
> Issue Type: Bug
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0, 2.2.1, 1.3.6, 1.4.11, 2.1.7
>
> Attachments: HBASE-22686-branch-1.patch, HBASE-22686.patch
>
>
> A region hosted by a crashed regionserver cannot be reassigned until the
> crashed regionserver's write-ahead logs have been processed and split into
> per-region recovered edits files. Reassignment of a region from a crashed
> server will be held up by the distributed split work backlog. Every
> regionserver runs a background daemon thread that manages the acquisition and
> execution of distributed log split tasks. This thread registers a watcher on
> a znode managed by the master. When the master is processing a server
> shutdown or crash or cluster restart when it detects the presence of
> unprocessed WAL files it will register the WAL files for processing under the
> znode. One or more live regionservers will attempt to get an exclusive lock
> on an entry. One of them wins, splits the WAL file, deletes the entry, then
> will acquire more work or go back to sleep if the worklist is empty. A
> regionserver can acquire at most a fixed number of log split tasks determined
> by configuration, hbase.regionserver.wal.max.splitters (default 2). If the
> number of entries/logs to process exceeds the number of available split
> workers in the cluster, perhaps due to the correlated failure of a
> significant subset of the fleet, then splitting work will fall behind.
> Regions may remain in RIT until the backlog is cleared.
> However, the regionserver side coordination logic -
> ZkSplitLogWorkerCoordination - only allows a regionserver to grab one task
> one at a time. Nearby javadoc says "This policy puts an upper-limit on the
> number of simultaneous log splitting that could be happening in a cluster."
> That upper limit will be the number of currently live regionservers. I don't
> feel I understand exactly why this is necessary or appropriate because a
> regionserver can handle more than one task at once and in fact the max number
> of concurrent split tasks it can accept is configurable.
> {code:java}
> /**
> * This function calculates how many splitters it could create based on
> expected average tasks per
> * RS and the hard limit upper bound(maxConcurrentTasks) set by
> configuration. <br>
> * At any given time, a RS allows spawn MIN(Expected Tasks/RS, Hard Upper
> Bound)
> * @param numTasks current total number of available tasks
> */
> private int calculateAvailableSplitters(int numTasks) {
> // at lease one RS(itself) available
> int availableRSs = 1;
> try {
> List<String> regionServers =
> ZKUtil.listChildrenNoWatch(watcher, watcher.rsZNode);
> availableRSs = Math.max(availableRSs, (regionServers == null) ? 0 :
> regionServers.size());
> } catch (KeeperException e) {
> // do nothing
> LOG.debug("getAvailableRegionServers got ZooKeeper exception", e);
> }
> int expectedTasksPerRS = (numTasks / availableRSs) + ((numTasks %
> availableRSs == 0) ? 0 : 1);
> expectedTasksPerRS = Math.max(1, expectedTasksPerRS); // at least be one
> // calculate how many more splitters we could spawn
> return Math.min(expectedTasksPerRS, maxConcurrentTasks)
> - this.tasksInProgress.get();
> {code}
> Shouldn't this simply be:
> {code:java}
> private int calculateAvailableSplitters() {
> return maxConcurrentTasks - tasksInProgress.get();
> }
> {code}
> ?
> This is branch-1.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
