Thanks so much! This describes exactly what I'm seeing. I did notice extremely heavy load on the region server carrying .META., as described in HBASE-6870:
In current logic, HTable#coprocessorExec always scan the whole table, its efficiency is low and will affect the Regionserver carrying .META. under large coprocessorExec requests Thanks again, Kim On Mon, Mar 4, 2013 at 8:08 PM, Stephen Boesch <java...@gmail.com> wrote: > great question from Kim and follow-up/answers. > > > 2013/3/4 Gary Helmling <ghelml...@gmail.com> > > > I see this is HBASE-6870. I thought that sounded familiar. > > > > > > On Mon, Mar 4, 2013 at 6:23 PM, Gary Helmling <ghelml...@gmail.com> > wrote: > > > > > > > > Check your logs for whether your end-point coprocessor is hitting > > >> zookeeper on every invocation to figure out the region start key. > > >> Unfortunately (at least last time I checked), the default way of > > invoking > > >> an end point coprocessor doesn't use the meta cache. You can go > through > > a > > >> combination of the following instead: > > >> HRegionLocation regionLocation = retried ? > > >> connection.relocateRegion(**tableName, tableKey) : > > >> connection.locateRegion(**tableName, tableKey); > > >> ... > > >> Then call HConnection.processExecs call, passing in the regionKeys > from > > >> above. > > >> You can trap the error case of the region being relocated and try > again > > >> with retried = true and it'll update the meta data cache when > > >> relocateRegion is called. > > >> > > > > > > > > > Any idea if we have an improvement logged in JIRA for this? This is > > > definitely something we should improve on. > > > > > >
