hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nkeywal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7247) Assignment performances decreased by 50% because of regionserver.OpenRegionHandler#tickleOpening
Date Wed, 05 Dec 2012 19:17:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510697#comment-13510697
] 

nkeywal commented on HBASE-7247:
--------------------------------

bq. On the 'post_region_open', IIRC, a bunch of these tickleOpenings were added because we
saw issues... in this case, an update of .META. that went in though we'd lost ownership of
the region.
Implicitly, it means we still have a race condition here, just that the probability is quite
low.

bq. Stepping back (after looking at code), could we drop the notion that a master can intercede
and assign a region elsewhere because it is proceeding too slow on a particular region in
the name of simplifying the region open handling interaction? There would be less noise in
the logs and less states to deal with.
It would be a huge simplification imho. It's worth trying, I would say. It actually makes
sense to do it now, because once the current trunk code will be production proven, touching
it will be scarier.

bq. Do we fail the open if the following break happens?
Yes, because updateMeta will return false.

bq. We have to call the + zkw.sync(node); ? We always did that? We are doing the sync just
to read the old znode value? Do we have to? Could we operate w/ stale read?
Well, we want to be sure that no one else wrote anything. It's often overkill, because we're
going to write the znode immediately after, so the sync will occur anyway during the write,
as we check the versions during the write. And it's expensive. So there is likely some room
for improvement here as well actually.


bq. HRegion region = this.rsServices.getFromOnlineRegions(encodedName);
We don't do anything here actually. We do a get, if the region is in the list, 'region' will
not be null and that's it. This variable is set later but not read in between. I can raise
an error if it's in the list? Hopefully it won't break anything (famous last words)


                
> Assignment performances decreased by 50% because of regionserver.OpenRegionHandler#tickleOpening
> ------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-7247
>                 URL: https://issues.apache.org/jira/browse/HBASE-7247
>             Project: HBase
>          Issue Type: Improvement
>          Components: master, Region Assignment, regionserver
>    Affects Versions: 0.96.0
>            Reporter: nkeywal
>            Assignee: nkeywal
>            Priority: Critical
>             Fix For: 0.96.0
>
>         Attachments: 7247.v1.patch
>
>
> The regionserver.OpenRegionHandler#tickleOpening updates the region znode as "Do this
so master doesn't timeout this region-in-transition.".
> However, on the usual test, this makes the assignment time of 1500 regions goes from
70s to 100s, that is, we're 50% slower because of this.
> More generally, ZooKeper commits to disk all the data update, and this takes time. Using
it to provide a keep alive seems overkill. At the very list, it could be made asynchronous.
> I'm not sure how necessary these updates are required (I need to go deeper in the internal,
feedback welcome), but it seems very important to optimize this... The trival fix would be
to make this optional.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message