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 5783C200CDE for ; Tue, 8 Aug 2017 22:52:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 561D0167F0E; Tue, 8 Aug 2017 20:52:05 +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 A1E72167F0C for ; Tue, 8 Aug 2017 22:52:04 +0200 (CEST) Received: (qmail 25695 invoked by uid 500); 8 Aug 2017 20:52:03 -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 25662 invoked by uid 99); 8 Aug 2017 20:52:03 -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; Tue, 08 Aug 2017 20:52:03 +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 2DD0AC05A7 for ; Tue, 8 Aug 2017 20:52:03 +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 unisyGoVsqSF for ; Tue, 8 Aug 2017 20:52:02 +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 134BB5FB2C for ; Tue, 8 Aug 2017 20:52:02 +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 23A1EE0D45 for ; Tue, 8 Aug 2017 20:52:01 +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 6A9932416D for ; Tue, 8 Aug 2017 20:52:00 +0000 (UTC) Date: Tue, 8 Aug 2017 20:52:00 +0000 (UTC) From: "Mike Drob (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18396) Encode ZNode names to reduce ZooKeeper jute buffer length requirements and thus reduce memory usage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 08 Aug 2017 20:52:05 -0000 [ https://issues.apache.org/jira/browse/HBASE-18396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119010#comment-16119010 ] Mike Drob commented on HBASE-18396: ----------------------------------- I don't know the exact sizes of paths, data, how many requests come in a batch, etc, so this is all going to be hypothetical. Say we have a typical ZK path of 100 bytes (and no data) and we're able to reduce that to 40 bytes. I don't expect to be able to go much further since I think there still need to be IDs or other non-colliding bits that exist, but say we map "replication" to "r" and so on. Theoretically, what used to take 1M will now only take 400K! That's a huge win! But! You go on to say that we can use this win to fit more requests in a single buffer. Well, then you'll have the same jute.maxbuffer len error, since it doesn't matter how big you make your buffer or how small you make the items if you keep adding until it overflows. I think saving network is a fine goal, but at the end of the day it's much more valuable to address the cause of the buffer exceeding instead of trying to optimize away the problems. Also, most systems I interact with have increased the maxbuffer to 4M and are running without issue. > Encode ZNode names to reduce ZooKeeper jute buffer length requirements and thus reduce memory usage > --------------------------------------------------------------------------------------------------- > > Key: HBASE-18396 > URL: https://issues.apache.org/jira/browse/HBASE-18396 > Project: HBase > Issue Type: Improvement > Affects Versions: 3.0.0 > Reporter: Karan Mehta > > In our production environment, we hit the error {{ZooKeeper connectionLoss due to jute.maxbuffer len of 1M getting exceeded}}. Usually 1 MB is a lot, but in case of multi requests, it can exceed the maximum buffer length that is allocated. > This JIRA is a discussion for encoding various znode names. IMO, this will reduce the path lengths, thus reducing the size of buffer required as well as network packet size and also pack more requests in a single multi. As with encoding, this will introduce overhead, but we need to determine how feasible this idea is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)