ipc numActiveHandler 已记录这里作为：
积极处理请求的 RPC 处理程序的数量
我正在寻找有关该指标重要性的更详细解释。我正在尝试调试一个场景，其中 numActiveHandler 卡在 32。我认为 32 是预先配置的最大值。
在此期间，同一个区域服务器的 CPU 消耗率停留在 100%。对于该区域服务器中的某个区域，处理读取请求的速率似乎因某种压力（某处存在瓶颈）而降低。读取请求延迟也增加了约 5 倍。
什么可能导致此行为？我的直觉是，在这段时间内与该区域服务器的连接过多，瓶颈是在处理读取请求之前。有什么建议下一步该怎么做吗？
更新
添加了 numActiveHandler 指标这里。该票上的描述是这样的：
我们发现 [numActiveHandler] 是衡量服务器繁忙程度的良好指标。如果此数字过高（与处理程序总数相比），则服务器存在呼叫队列已满的风险。
更新2
在同一时期，另一个指标hbase.regionserver.ipc.numCallsInGeneralQueue也表现异常。附上一张显示它们一起的图表。
更新3
我们的hbase版本cdh5-1.2.0_5.11.0来自 https://github.com/cloudera/hbase/tree/cdh5-1.2.0_5.11.0
不幸的是，我没有相关numActive<OperationName>Handler指标 :( 但是，从其他现有指标来看，我确信罪魁祸首是 scanNext 请求。稍后会详细介绍。
对于@spats建议的其他参数，我需要进行一些调查和调整。
hbase.regionserver.handler.count 文档提到：
从两倍的 CPU 数量开始并从那里进行调整。
查看 CPU 数量，我可以将其设置为 50，而不是默认值 30。
无论如何，30、50 听起来太小了，我很难理解它们的影响。这个区域服务器每秒可以处理 2000 个 scanNext 请求。这是通过 30 个处理程序实现的吗？这些处理程序是否类似于执行线程？它们与区域服务器可以处理的并行请求数有关吗？这难道不是一个很小的数字吗？
hbase.ipc.server.callqueue.handler.factor还提到这里，其默认值为0.1。
使用默认值 30 个处理程序计数，这将产生 3 个队列。我很难理解这种权衡。如果我将设置hbase.ipc.server.callqueue.handler.factor为 1，每个处理程序将有自己的队列。这种配置会带来什么不利影响？
更新4
罪魁祸首是 scanNext 请求发送到该区域服务器。然而情况更加复杂。
下图包括同一区域服务器上的 scanNext 操作计数。请注意，y 轴现在采用对数刻度。
在异常开始时（下午 4:15），scanNext 请求数量有所增加。据我了解，发送请求的服务的 scanNext 请求数量一定更大下午 4:15 至 5:20 之间比下午 5:20 之后的扫描请求数多。我不知道下午 4:15 至 5:20 之间的 scanNext 请求数具体是多少，但我未经证实的粗略计算表明该请求数应该多 5% 左右。
因此，我认为这个 scanNext num ops 指标具有误导性。它可能是已完成的 scanNext 操作数。在下午 4:15 到下午 5:20 之间，我认为区域服务器被其他东西阻塞，无法完成 scanNext 操作。
numActiveHandler而且，无论阻碍是什么，我认为我们都能从和 指标的异常中了解情况numCallsInGeneralQueue。但我很难找到一份好的架构文档，该文档可以提供有关这些指标以及可能导致异常的原因的见解。
答案1
它可能是任何请求，例如扫描、写入等，而不仅仅是读取请求。您能否从指标 hbase.regionserver.ipc.numActiveScanHandler、hbase.regionserver.ipc.numActiveReadHandler 等检查出哪种请求导致了此峰值？
如果您的有效载荷很小，请尝试增加 hbase.regionserver.handler.count？
如果写入导致峰值，请尝试增加 hbase.client.write.buffer（假设内存没有峰值）
如果您希望读取/扫描/写入中的任何峰值不会互相影响，那么分离调用队列和处理程序也是一个好主意。hbase.ipc.server.callqueue.handler.factor & hbase.ipc.server.callqueue.read.ratio