[jira] [Created] (HBASE-16277) Improve CPU efficiency in VisibilityLabelsCache

["Gary Helmling (JIRA)" <ji...@apache.org>]

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)