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 12348200D5A for ; Thu, 14 Dec 2017 19:25:06 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 1057A160C16; Thu, 14 Dec 2017 18:25:06 +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 55EF9160BFC for ; Thu, 14 Dec 2017 19:25:05 +0100 (CET) Received: (qmail 48383 invoked by uid 500); 14 Dec 2017 18:25:04 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 48372 invoked by uid 99); 14 Dec 2017 18:25:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Dec 2017 18:25:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id C8B0E1807A1 for ; Thu, 14 Dec 2017 18:25:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-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 (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id oVFHZv3yh5MS for ; Thu, 14 Dec 2017 18:25:02 +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 C94695FB87 for ; Thu, 14 Dec 2017 18:25:01 +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 A5415E129D for ; Thu, 14 Dec 2017 18:25:00 +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 356BF212FD for ; Thu, 14 Dec 2017 18:25:00 +0000 (UTC) Date: Thu, 14 Dec 2017 18:25:00 +0000 (UTC) From: "Lars Hofhansl (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-4460) High GC / RS shutdown when we use select query with "IN" clause using 4.10 phoenix client on 4.13 phoenix server MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 14 Dec 2017 18:25:06 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16291300#comment-16291300 ] Lars Hofhansl commented on PHOENIX-4460: ---------------------------------------- That's it? Can you explain? :) > High GC / RS shutdown when we use select query with "IN" clause using 4.10 phoenix client on 4.13 phoenix server > ---------------------------------------------------------------------------------------------------------------- > > Key: PHOENIX-4460 > URL: https://issues.apache.org/jira/browse/PHOENIX-4460 > Project: Phoenix > Issue Type: Bug > Reporter: James Taylor > Assignee: James Taylor > Priority: Blocker > Fix For: 4.14.0, 4.13.2 > > Attachments: PHOENIX-4460.patch > > > We were able to reproduce the High GC / RS shutdown / phoenix KeyRange query high object count issue on cluster today. > Main observation is that this is reproducible when firing lots of query select from xyz where abc in (?, ?, ...) of this type with 4.10 phoenix client hitting 4.13 phoenix on HBase server side > (4.10 client/4.10 server works fine, 4.13 client with 4.13 server works fine) > We wrote a loader client (attached) with the below table/query , upserted ~100 million rows and fired the query in parallel using 4-5 loader clients with 16 threads each > {code} > TABLE: = "CREATE TABLE " + TABLE_NAME_TEMPLATE > + " (\n" + " TestKey varchar(255) PRIMARY KEY, TestVal1 varchar(200), TestVal2 varchar(200), " + "TestValue varchar(10000))"; > QUERY: = "SELECT * FROM " + TABLE_NAME_TEMPLATE + " WHERE TestKey IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)" > {code} > After running this client immediately within a min or two we see the phoenix.query.KeyRange object count immediately going up to several lakhs and keeps on increasing continuously. This count doesn't seem to come down even after shutting down the clients > {code} > -bash-4.1$ ~/current/bigdata-util/tools/Linux/jdk/jdk1.8.0_102_x64/bin/jmap -histo:live 90725 | grep KeyRange > 47: 274852 6596448 org.apache.phoenix.query.KeyRange > 1851: 2 48 org.apache.phoenix.query.KeyRange$Bound > 2434: 1 24 [Lorg.apache.phoenix.query.KeyRange$Bound; > 3411: 1 16 org.apache.phoenix.query.KeyRange$1 > 3412: 1 16 org.apache.phoenix.query.KeyRange$2 > {code} > After some time we also started seeing High GC issues and RegionServers crashing > Experiment Summary: > - 4.13 client/4.13 Server --- Issue not reproducible (we do see KeyRange count increasing upto few 100's) > - 4.10 client/4.10 Server --- Issue not reproducible (we do see KeyRange count increasing upto few 100's) > - 4.10 client/4.13 Server --- Issue reproducible as described above -- This message was sent by Atlassian JIRA (v6.4.14#64029)