hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashish Singhi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
Date Wed, 02 Mar 2016 13:09:18 GMT

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

Ashish Singhi commented on HBASE-9393:

bq. Are the characteristics of stream something we can determine in a static initializer from
configs, perhaps by instantiating a dummy version?
No we cannot do that way. I checked the code and the same is stated in the javadoc
  /** Two stream handles, one with and one without FS-level checksum.
   * HDFS checksum setting is on FS level, not single read level, so you have to keep two
   * FS objects and two handles open to interleave different reads freely, which is very sad.
   * This is what we do:
   * 1) First, we need to read the trailer of HFile to determine checksum parameters.
   *  We always use FS checksum to do that, so ctor opens {@link #stream}.
   * 2.1) After that, if HBase checksum is not used, we'd just always use {@link #stream};
   * 2.2) If HBase checksum can be used, we'll open {@link #streamNoFsChecksum},
   *  and close {@link #stream}. User MUST call prepareForBlockReader for that to happen;
   *  if they don't, (2.1) will be the default.
   * 3) The users can call {@link #shouldUseHBaseChecksum()}, and pass its result to
   *  {@link #getStream(boolean)} to get stream (if Java had out/pointer params we could
   *  return both in one call). This stream is guaranteed to be set.
   * 4) The first time HBase checksum fails, one would call {@link #fallbackToFsChecksum(int)}.
   * That will take lock, and open {@link #stream}. While this is going on, others will
   * continue to use the old stream; if they also want to fall back, they'll also call
   * {@link #fallbackToFsChecksum(int)}, and block until {@link #stream} is set.
   * 5) After some number of checksumOk() calls, we will go back to using HBase checksum.
   * We will have 2 handles; however we presume checksums fail so rarely that we don't care.
The value of hbase checksum and stream will be used cannot be determined in a static initializer.
I think unbuffer method type should be a instance variable and cannot be shared.

> Hbase does not closing a closed socket resulting in many CLOSE_WAIT 
> --------------------------------------------------------------------
>                 Key: HBASE-9393
>                 URL: https://issues.apache.org/jira/browse/HBASE-9393
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.94.2, 0.98.0
>         Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, 7279 regions
>            Reporter: Avi Zrachya
>            Assignee: Ashish Singhi
>            Priority: Critical
>             Fix For: 2.0.0
>         Attachments: HBASE-9393.patch, HBASE-9393.v1.patch, HBASE-9393.v10.patch, HBASE-9393.v11.patch,
HBASE-9393.v12.patch, HBASE-9393.v13.patch, HBASE-9393.v2.patch, HBASE-9393.v3.patch, HBASE-9393.v4.patch,
HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch,
HBASE-9393.v6.patch, HBASE-9393.v7.patch, HBASE-9393.v8.patch, HBASE-9393.v9.patch
> HBase dose not close a dead connection with the datanode.
> This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect to the
datanode because too many mapped sockets from one host to another on the same port.
> The example below is with low CLOSE_WAIT count because we had to restart hbase to solve
the porblem, later in time it will incease to 60-100K sockets on CLOSE_WAIT
> [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l
> 13156
> [root@hd2-region3 ~]# ps -ef |grep 21592
> root     17255 17219  0 12:26 pts/0    00:00:00 grep 21592
> hbase    21592     1 17 Aug29 ?        03:29:06 /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill
-9 %p -Xmx8000m -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -Dhbase.log.dir=/var/log/hbase
-Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ...

This message was sent by Atlassian JIRA

View raw message