Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9E628200C5C for ; Thu, 6 Apr 2017 01:27:45 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 9CD94160B94; Wed, 5 Apr 2017 23:27:45 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E4243160B9E for ; Thu, 6 Apr 2017 01:27:44 +0200 (CEST) Received: (qmail 61112 invoked by uid 500); 5 Apr 2017 23:27:44 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 61097 invoked by uid 99); 5 Apr 2017 23:27:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Apr 2017 23:27:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 84098C04DE for ; Wed, 5 Apr 2017 23:27:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id IBGl0GytXmtP for ; Wed, 5 Apr 2017 23:27:42 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 5CE985FBA1 for ; Wed, 5 Apr 2017 23:27:42 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id E7A20E0B08 for ; Wed, 5 Apr 2017 23:27:41 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id A5FF6263C6 for ; Wed, 5 Apr 2017 23:27:41 +0000 (UTC) Date: Wed, 5 Apr 2017 23:27:41 +0000 (UTC) From: "Sean Busbey (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-15871) Memstore flush doesn't finish because of backwardseek() in memstore scanner. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 05 Apr 2017 23:27:45 -0000 [ https://issues.apache.org/jira/browse/HBASE-15871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958010#comment-15958010 ] Sean Busbey commented on HBASE-15871: ------------------------------------- This landed in the master branch in ~Oct 2016, and is in no other branches ATM. [~ram_krish] are you still planning to include a branch-1 version, or should we close this out and open a follow-on to track a solution for branch-1? > Memstore flush doesn't finish because of backwardseek() in memstore scanner. > ---------------------------------------------------------------------------- > > Key: HBASE-15871 > URL: https://issues.apache.org/jira/browse/HBASE-15871 > Project: HBase > Issue Type: Bug > Components: Scanners > Affects Versions: 1.1.2 > Reporter: Jeongdae Kim > Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15871_1.patch, HBASE-15871_1.patch, HBASE-15871_2.patch, HBASE-15871_3.patch, HBASE-15871_4.patch, HBASE-15871_6.patch, HBASE-15871.branch-1.1.001.patch, HBASE-15871.branch-1.1.002.patch, HBASE-15871.branch-1.1.003.patch, HBASE-15871-branch-1.patch, HBASE-15871.patch, memstore_backwardSeek().PNG > > > Sometimes in our production hbase cluster, it takes a long time to finish memstore flush.( for about more than 30 minutes) > the reason is that a memstore flusher thread calls StoreScanner.updateReaders(), waits for acquiring a lock that store scanner holds in StoreScanner.next() and backwardseek() in memstore scanner runs for a long time. > I think that this condition could occur in reverse scan by the following process. > 1) create a reversed store scanner by requesting a reverse scan. > 2) flush a memstore in the same HStore. > 3) puts a lot of cells in memstore and memstore is almost full. > 4) call the reverse scanner.next() and re-create all scanners in this store because all scanners was already closed by 2)'s flush() and backwardseek() with store's lastTop for all new scanners. > 5) in this status, memstore is almost full by 2) and all cells in memstore have sequenceID greater than this scanner's readPoint because of 2)'s flush(). this condition causes searching all cells in memstore, and seekToPreviousRow() repeatly seach cells that are already searched if a row has one column. (described this in more detail in a attached file.) > 6) flush a memstore again in the same HStore, and wait until 4-5) process finished, to update store files in the same HStore after flusing. > I searched HBase jira. and found a similar issue. (HBASE-14497) but, HBASE-14497's fix can't solve this issue because that fix just changed recursive call to loop.(and already applied to our HBase version) -- This message was sent by Atlassian JIRA (v6.3.15#6346)