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 969C4200B57 for ; Sat, 23 Jul 2016 01:14:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 9514D160A6D; Fri, 22 Jul 2016 23:14:22 +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 DCC0B160A8E for ; Sat, 23 Jul 2016 01:14:21 +0200 (CEST) Received: (qmail 42620 invoked by uid 500); 22 Jul 2016 23:14:20 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 42600 invoked by uid 99); 22 Jul 2016 23:14:20 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2016 23:14:20 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 6D2752C0278 for ; Fri, 22 Jul 2016 23:14:20 +0000 (UTC) Date: Fri, 22 Jul 2016 23:14:20 +0000 (UTC) From: "Gary Helmling (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-16277) Improve CPU efficiency in VisibilityLabelsCache MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 22 Jul 2016 23:14:22 -0000 Gary Helmling created HBASE-16277: ------------------------------------- Summary: Improve CPU efficiency in VisibilityLabelsCache Key: HBASE-16277 URL: https://issues.apache.org/jira/browse/HBASE-16277 Project: HBase Issue Type: Improvement Components: security Reporter: Gary Helmling For secure clusters where the VisibilityController coprocessor is loaded, regionservers sometimes degrade into very high CPU utilization, with many of the RPC handler threads stuck in: {noformat} "B.defaultRpcServer.handler=0,queue=0,port=16020" #114 daemon prio=5 os_prio=0 tid=0x00007f8a95bb7800 nid=0x382 runnable [0x00007f8a3051f000] java.lang.Thread.State: RUNNABLE at java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntry(ThreadLocal.java:617) at java.lang.ThreadLocal$ThreadLocalMap.remove(ThreadLocal.java:499) at java.lang.ThreadLocal$ThreadLocalMap.access$200(ThreadLocal.java:298) at java.lang.ThreadLocal.remove(ThreadLocal.java:222) at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:426) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881) at org.apache.hadoop.hbase.security.visibility.VisibilityLabelsCache.getGroupAuths(VisibilityLabelsCache.java:237) at org.apache.hadoop.hbase.security.visibility.FeedUserAuthScanLabelGenerator.getLabels(FeedUserAuthScanLabelGenerator.java:70) at org.apache.hadoop.hbase.security.visibility.DefaultVisibilityLabelServiceImpl.getVisibilityExpEvaluator(DefaultVisibilityLabelServiceImpl.java:469) at org.apache.hadoop.hbase.security.visibility.VisibilityUtils.createVisibilityLabelFilter(VisibilityUtils.java:284) at org.apache.hadoop.hbase.security.visibility.VisibilityController.preGetOp(VisibilityController.java:684) at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$26.call(RegionCoprocessorHost.java:849) at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673) at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1749) at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1705) at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preGet(RegionCoprocessorHost.java:845) at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:6748) at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:6736) at org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2029) at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:33644) at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2170) at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:109) at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:137) at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:112) at java.lang.Thread.run(Thread.java:745) {noformat} In this case there are no visibility labels actually in use, so it appears that the locking overhead for the VisibilityLabelsCache can reach a tipping point where it does not degrade gracefully. We should look at alternate approaches to the label caching in place of the current ReentrantReadWriteLock. -- This message was sent by Atlassian JIRA (v6.3.4#6332)