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 7256D200C5C for ; Thu, 6 Apr 2017 06:40:49 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 70E62160B9E; Thu, 6 Apr 2017 04:40:49 +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 B98CA160B94 for ; Thu, 6 Apr 2017 06:40:48 +0200 (CEST) Received: (qmail 11515 invoked by uid 500); 6 Apr 2017 04:40:47 -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 11504 invoked by uid 99); 6 Apr 2017 04:40:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Apr 2017 04:40:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 5F32D1A07BB for ; Thu, 6 Apr 2017 04:40:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-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-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id hSa2wXP6KTrN for ; Thu, 6 Apr 2017 04:40:46 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 14EB45FCD9 for ; Thu, 6 Apr 2017 04:40:45 +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 0876CE0D2E for ; Thu, 6 Apr 2017 04:40:44 +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 5DF7E24095 for ; Thu, 6 Apr 2017 04:40:42 +0000 (UTC) Date: Thu, 6 Apr 2017 04:40:42 +0000 (UTC) From: "ramkrishna.s.vasudevan (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (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: Thu, 06 Apr 2017 04:40:49 -0000 [ https://issues.apache.org/jira/browse/HBASE-15871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15871: ------------------------------------------- Resolution: Fixed Status: Resolved (was: Patch Available) > 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)