Каково значение метрики hbase.regionserver.ipc.numActiveHandler?

IPc numActiveHandler задокументирован Вот так как:

Количество обработчиков RPC, активно обслуживающих запросы

Я ищу более подробное объяснение значения этой метрики. Я пытаюсь отладить сценарий, в котором numActiveHandler застревает на 32. Я думаю, что 32 - это предварительно настроенный максимум.

В это время тот же региональный сервер зависает на 100% потреблении ЦП. Для одного из регионов на этом сервере reqionserver скорость обработанных запросов на чтение выглядит так, как будто они уменьшаются из-за некоторого давления, узкого места где-то. Задержки запросов на чтение также увеличиваются примерно в 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 документы упомянуть:

Начните с удвоенного количества ЦП и настраивайте оттуда.

Глядя на количество ЦП, я мог бы установить его на 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 находится в логарифмической шкале.

В начале аномалии (16:15) был рост запросов scanNext. Из того, что я знаю о службе, отправившей запросы, счетчик запросов scanNext должно быть было больше с 16:15 до 17:20 по сравнению с более поздним периодом, чем 17:20. Я не знаю точного номера запроса scanNext между 16:15 и 17:20, мой неподтвержденный расчет на обратной стороне конверта предполагает, что он должен быть примерно на 5% больше.

Из-за этого я считаю, что этот показатель scanNext num ops вводит в заблуждение. Это может быть счетчик выполненных операций scanNext. Между 16:15 и 17:20 я думаю, что региональный сервер был заблокирован для чего-то еще и не мог завершить операции scanNext.

И что бы там ни было, я думал, мы можем понять аномалию в numActiveHandler и numCallsInGeneralQueue метрики. Но мне трудно найти хороший архитектурный документ, который дает представление об этих показателях и о том, что может вызвать эту аномалию.