The split is done by the region servers (the master coordinates). Is there
some interesting stuff in their logs?

On Fri, Mar 20, 2015 at 3:38 PM, Dejan Menges <dejan.men...@gmail.com>
wrote:

> With client issue was that it was retrying connecting to the same region
> servers even when they were reassigned. Lowering it down helped in this
> specific use case, but yes, we still want servers to reallocate quickly.
>
> What got me here:
>
> http://hbase.apache.org/book.html#mttr
>
> I basically set configuration exactly the same way as it's explained here.
> *zookeeper.session.timeout* is (and was before) 60000 (one minute).
>
> So basically what happens is: - simulating network issues we had recently).
> - After short time I see in HBase that my RegionServer is dead, and as
> total number of regions I see previous total minus number of regions that
> were hosted on the node hosting RegionServer that just 'disappeared'.
> - In this point I want my clus
>
> - I have test cluster consisting of four nodes, every node being DataNode
> and RegionServer.
> - I simulate network partition on one (connect to it through console and
> take network interface downter to recover as soon as possible, to start
> serving missing regions.
> - First thing I see in HMaster logs are:
>
> 2015-03-20 14:17:26,015 INFO
> org.apache.hadoop.hbase.zookeeper.RegionServerTracker: RegionServer
> ephemeral node deleted, processing expiration
> [{name_of_node_I_took_down},60020,1426860403261]
>
> 2015-03-20 14:17:26,067 INFO
> org.apache.hadoop.hbase.master.handler.ServerShutdownHandler: Splitting
> logs for {name_of_node_I_took_down},60020,1426860403261 before assignment.
>
> 2015-03-20 14:17:26,105 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: dead splitlog workers [
> {name_of_node_I_took_down},60020,1426860403261]
>
> 2015-03-20 14:17:26,107 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: started splitting 1 logs in
> [hdfs://{fqdn_of_hmaster}:8020/hbase/WALs/{name_of_node_I_took_down}
> ,60020,1426860403261-splitting]
>
> 2015-03-20 14:17:26,150 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: task
> /hbase/splitWAL/WALs%2F
> {name_of_node_I_took_down}%2C60020%2C1426860403261-splitting%2F
> {name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905
> acquired by {fqdn_of_another_live_hnode},60020,1426859445623
>
> 2015-03-20 14:17:26,182 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: total tasks = 1 unassigned
> = 0 tasks={/hbase/splitWAL/WALs%2F{name_of_node_I_took_down}
>
> %2C60020%2C1426860403261-splitting%2F{name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905=last_update
> = 1426861046182 last_version = 2 cur_worker_name =
> {fqdn_of_another_live_node},60020,1426859445623 status = in_progress
> incarnation = 0 resubmits = 0 batch = installed = 1 done = 0 error = 0}
>
> 2015-03-20 14:17:31,183 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: total tasks = 1 unassigned
> = 0 tasks={/hbase/splitWAL/WALs%2F{name_of_node_I_took_down}
>
> %2C60020%2C1426860403261-splitting%2F{name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905=last_update
> = 1426861046182 last_version = 2 cur_worker_name =
> {fqdn_of_another_live_node},60020,1426859445623 status = in_progress
> incarnation = 0 resubmits = 0 batch = installed = 1 done = 0 error = 0}
>
> 2015-03-20 14:17:36,184 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: total tasks = 1 unassigned
> = 0 tasks={/hbase/splitWAL/WALs%2F{name_of_node_I_took_down}
>
> %2C60020%2C1426860403261-splitting%2F{name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905=last_update
> = 1426861046182 last_version = 2 cur_worker_name =
> {fqdn_of_another_live_node},60020,1426859445623 status = in_progress
> incarnation = 0 resubmits = 0 batch = installed = 1 done = 0 error = 0}
>
> 2015-03-20 14:17:42,185 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: total tasks = 1 unassigned
> = 0 tasks={/hbase/splitWAL/WALs%2F{name_of_node_I_took_down}
>
> %2C60020%2C1426860403261-splitting%2F{name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905=last_update
> = 1426861046182 last_version = 2 cur_worker_name =
> {fqdn_of_another_live_node},60020,1426859445623 status = in_progress
> incarnation = 0 resubmits = 0 batch = installed = 1 done = 0 error = 0}
>
> 2015-03-20 14:17:48,184 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: total tasks = 1 unassigned
> = 0 tasks={/hbase/splitWAL/WALs%2F{name_of_node_I_took_down}
>
> %2C60020%2C1426860403261-splitting%2F{name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905=last_update
> = 1426861046182 last_version = 2 cur_worker_name =
> {fqdn_of_another_live_node},60020,1426859445623 status = in_progress
> incarnation = 0 resubmits = 0 batch = installed = 1 done = 0 error = 0}
> In the meantime, In hbase...out log I got this:
>
> ==> hbase-hbase-master-{fqdn_of_my_hmaster_node}.out <==
>
> java.io.IOException: Call to
> {name_of_node_I_took_down}/{ip_of_local_interface_I_took_down}:60020
> failed on local exception:
> org.apache.hadoop.hbase.ipc.RpcClient$CallTimeoutException: Call
> id=93152, waitTime=60044, rpcTimeout=60000
>
> at org.apache.hadoop.hbase.ipc.RpcClient.wrapException(RpcClient.java:1532)
>
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1502)
>
> at
>
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1684)
>
> at
>
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1737)
>
> at
>
> org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$BlockingStub.getRegionInfo(AdminProtos.java:20806)
>
> at
>
> org.apache.hadoop.hbase.client.HBaseAdmin.getCompactionState(HBaseAdmin.java:2524)
>
> at
>
> org.apache.hadoop.hbase.generated.master.table_jsp._jspService(table_jsp.java:167)
>
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
>
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>
> at
>
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
>
> at
>
> org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
>
> at
>
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>
> at
>
> org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1081)
>
> at
>
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>
> at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
>
> at
>
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>
> at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>
> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>
> at
>
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>
> at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>
> at org.mortbay.jetty.Server.handle(Server.java:326)
>
> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>
> at
>
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
>
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>
> at
>
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>
> at
>
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>
> Caused by: org.apache.hadoop.hbase.ipc.RpcClient$CallTimeoutException: Call
> id=93152, waitTime=60044, rpcTimeout=60000
>
> at
>
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.cleanupCalls(RpcClient.java:1234)
>
> at
>
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.readResponse(RpcClient.java:1171)
>
> at org.apache.hadoop.hbase.ipc.RpcClient$Connection.run(RpcClient.java:751)
> Beside this same issue, please note that first message was at 2015-03-20
> 14:17:26,015. And then (we got to the point when it started transition):
>
> 2015-03-20 14:32:35,059 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: task
> /hbase/splitWAL/WALs%2F
> {name_of_node_I_took_down}%2C60020%2C1426860403261-splitting%2F
> {name_of_node_I_took_down}%252C60020%252C1426860403261.1426860404905
> entered state: DONE {fqdn_of_new_live_node},60020,1426859445623
>
> 2015-03-20 14:32:35,109 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: Done splitting
> /hbase/splitWAL/WALs%2F{name_of_node_I_took_down}
> %2C60020%2C1426860403261-splitting%2F{name_of_node_I_took_down}
> %252C60020%252C1426860403261.1426860404905
>
> 2015-03-20 14:32:35,190 INFO
> org.apache.hadoop.hbase.master.SplitLogManager: finished splitting (more
> than or equal to) 9 bytes in 1 log files in
>
> [hdfs://{fqdn_of_my_hmaster_node}:8020/hbase/WALs/{name_of_node_I_took_down},60020,1426860403261-splitting]
> in 909083ms
>
> 2015-03-20 14:32:35,191 INFO org.apache.hadoop.hbase.master.RegionStates:
> Transitioned {0e7cc87a4ef6c47a779186f5bf79a01c state=OPEN,
> ts=1426860639088, server={name_of_node_I_took_down},60020,1426860403261} to
> {0e7cc87a4ef6c47a779186f5bf79a01c state=OFFLINE, ts=1426861955191, server=
> {name_of_node_I_took_down},60020,1426860403261}
>
> 2015-03-20 14:32:35,191 INFO org.apache.hadoop.hbase.master.RegionStates:
> Offlined 0e7cc87a4ef6c47a779186f5bf79a01c from {name_of_node_I_took_down}
> ,60020,1426860403261
>
> 2015-03-20 14:32:35,191 INFO org.apache.hadoop.hbase.master.RegionStates:
> Transitioned {25ab6e7b42e36ddaa723d71be5954543 state=OPEN,
> ts=1426860641783, server={name_of_node_I_took_down},60020,1426860403261} to
> {25ab6e7b42e36ddaa723d71be5954543 state=OFFLINE, ts=1426861955191, server=
> {name_of_node_I_took_down},60020,1426860403261}
>
> 2015-03-20 14:32:35,191 INFO org.apache.hadoop.hbase.master.RegionStates:
> Offlined 25ab6e7b42e36ddaa723d71be5954543 from {name_of_node_I_took_down}
> ,60020,1426860403261
> At this point, note that it finished SplitLogManager task at 14:32:35 and
> started transitioning just after that. So this is 15 minutes that I'm
> talking about.
>
> What am I missing?
>
>
> On Fri, Mar 20, 2015 at 2:37 PM Nicolas Liochon <nkey...@gmail.com> wrote:
>
> > You've changed the value of hbase.zookeeper.timeout to 15 minutes? A very
> > reasonable target is 1 minute before relocating the regions. That's the
> > default iirc. You can push it to 20s, but then gc-stopping-the-world
> > becomes more of an issue. 15 minutes is really a lot. The hdfs stale mode
> > must always be used, with a lower timeout than the hbase one.
> >
> > Client side there should be nothing to do (excepted for advanced stuff);
> at
> > each retry the client checks the location of the regions. If you lower
> the
> > number of retry the client will fail sooner, but usually you don't want
> the
> > client to fail, you want the servers to reallocate quickly.
> >
> > On Fri, Mar 20, 2015 at 1:36 PM, Dejan Menges <dejan.men...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Sorry for little bit late update, but managed to narrow it little bit
> > down.
> > >
> > > We didn't update yet, as we are using Hortonworks distribution right
> now,
> > > and even if we update we will get 0.98.4. However, looks that issue
> here
> > > was in our use case and configuration (still looking into it).
> > >
> > > Basically, initially I saw that when one server goes down, we start
> > having
> > > performance issues in general, but it managed to be on our client side,
> > due
> > > to caching, and clients were trying to reconnect to nodes that were
> > offline
> > > and later trying to get regions from those nodes too. This is basically
> > why
> > > on server side I didn't manage to see anything in logs that would be at
> > > least little bit interesting and point me into desired direction.
> > >
> > > Another question that popped up to me is - in case server is down (and
> > with
> > > it DataNode and HRegionServer it was hosting) - what's optimal time to
> > set
> > > for HMaster to consider server dead reassign regions somewhere else, as
> > > this is another performance bottleneck we hit during inability to
> access
> > > regions? In our case it's configured to 15 minutes, and simple logic
> > tells
> > > me if you want it earlier then configure lower number of retries, but
> > issue
> > > is as always in details, so not sure if anyone knows some better math
> for
> > > this?
> > >
> > > And last question - is it possible to manually force HBase to reassign
> > > regions? In this case, while HMaster is retrying to contact node that's
> > > dead, it's impossible to force it using 'balancer' command.
> > >
> > > Thanks a lot!
> > >
> > > Dejan
> > >
> > > On Tue, Mar 17, 2015 at 9:37 AM Dejan Menges <dejan.men...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > To be very honest - there's no particular reason why we stick to this
> > > one,
> > > > beside just lack of time currently to go through upgrade process, but
> > > looks
> > > > to me that's going to be next step.
> > > >
> > > > Had a crazy day, didn't have time to go through all logs again, plus
> > one
> > > > of the machines (last one where we had this issue) is fully
> > reprovisioned
> > > > yesterday so I don't have logs from there anymore.
> > > >
> > > > Beside upgrading,  what I will talk about today, can you just point
> me
> > to
> > > > the specific RPC issue in 0.98.0? Thing is that we have some strange
> > > > moments with RPC in this case, and just want to see if that's the
> same
> > > > thing (and we were even suspecting to RPC).
> > > >
> > > > Thanks a lot!
> > > > Dejan
> > > >
> > > > On Mon, Mar 16, 2015 at 9:32 PM, Andrew Purtell <apurt...@apache.org
> >
> > > > wrote:
> > > >
> > > >> Is there a particular reason why you are using HBase 0.98.0? The
> > latest
> > > >> 0.98 release is 0.98.11. There's a known performance issue with
> 0.98.0
> > > >> pertaining to RPC that was fixed in later releases, you should move
> up
> > > >> from
> > > >> 0.98.0. In addition hundreds of improvements and bug fixes have gone
> > > into
> > > >> the ten releases since 0.98.0.
> > > >>
> > > >> On Mon, Mar 16, 2015 at 6:40 AM, Dejan Menges <
> dejan.men...@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > Hi All,
> > > >> >
> > > >> > We have a strange issue with HBase performance (overall cluster
> > > >> > performance) in case one of datanodes in the cluster unexpectedly
> > goes
> > > >> > down.
> > > >> >
> > > >> > So scenario is like follows:
> > > >> > - Cluster works fine, it's stable.
> > > >> > - One DataNode unexpectedly goes down (PSU issue, network issue,
> > > >> anything)
> > > >> > - Whole HBase cluster goes down (performance becomes so bad that
> we
> > > >> have to
> > > >> > restart all RegionServers to get it back to life).
> > > >> >
> > > >> > Most funny and latest issue that happened was that we added new
> node
> > > to
> > > >> the
> > > >> > cluster (having 8 x 4T SATA disks) and we left just DataNode
> running
> > > on
> > > >> it
> > > >> > to give it couple of days to get some data. At some point in time,
> > due
> > > >> to
> > > >> > hardware issue, server rebooted (twice during three hours) in
> moment
> > > >> when
> > > >> > it had maybe 5% of data it would have in a couple of days. Nothing
> > > else
> > > >> > beside DataNode was running, and once it went down, it affected
> > > literary
> > > >> > everything, and restarting RegionServers in the end fixed it.
> > > >> >
> > > >> > We are using HBase 0.98.0 with Hadoop 2.4.0
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >>
> > > >>    - Andy
> > > >>
> > > >> Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > >> (via Tom White)
> > > >>
> > > >
> > > >
> > >
> >
>

Reply via email to