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 8DC9C200C55 for ; Thu, 30 Mar 2017 03:14:46 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 8C390160B9D; Thu, 30 Mar 2017 01:14:46 +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 D50BD160B8A for ; Thu, 30 Mar 2017 03:14:45 +0200 (CEST) Received: (qmail 27965 invoked by uid 500); 30 Mar 2017 01:14:45 -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 27943 invoked by uid 99); 30 Mar 2017 01:14:45 -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, 30 Mar 2017 01:14:45 +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 7288E1A047A for ; Thu, 30 Mar 2017 01:14:44 +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-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id lpWOJlnWonRh for ; Thu, 30 Mar 2017 01:14:43 +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 1066E5FE44 for ; Thu, 30 Mar 2017 01:14:43 +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 935B6E0959 for ; Thu, 30 Mar 2017 01:14:42 +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 C263A2417C for ; Thu, 30 Mar 2017 01:14:41 +0000 (UTC) Date: Thu, 30 Mar 2017 01:14:41 +0000 (UTC) From: "huaxiang sun (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17215) Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 30 Mar 2017 01:14:46 -0000 [ https://issues.apache.org/jira/browse/HBASE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15948201#comment-15948201 ] huaxiang sun commented on HBASE-17215: -------------------------------------- Thanks [~carp84] for the patch! The patch looks great. I went through the patch and left couple comments there. Maybe as a followup, can these two threads share a LinkedBlockingDeque? So large-size file is added to the head of the queue and small-size files are added to the tail. the large-file-thread poll from the head and the small-file-thread poll from the end. In this sense, no thread will be idle when there are works to do. What do you think? > Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed > --------------------------------------------------------------------------------------------------- > > Key: HBASE-17215 > URL: https://issues.apache.org/jira/browse/HBASE-17215 > Project: HBase > Issue Type: Improvement > Reporter: Yu Li > Assignee: Yu Li > Attachments: HBASE-17215.patch > > > When using PCIe-SSD the flush speed will be really quick, and although we have per CF flush, we still have the {{hbase.regionserver.optionalcacheflushinterval}} setting and some other mechanism to avoid data kept in memory for too long to flush small hfiles. In our online environment we found the single thread cleaner kept cleaning earlier flushed small files while large files got no chance, which caused disk full then many other problems. > Deleting hfiles in parallel with too many threads will also increase the workload of namenode, so here we propose to separate large/small hfile cleaner threads just like we do for compaction, and it turned out to work well in our cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)