Этот раздел обеспечивает направляющие линии при установке системных переменных пула потоков для лучшей производительности, измеренное использование метрики, таких как транзакции в секунду.

thread_pool_size самый важный параметр, управляющий производительностью пула потоков. Это может быть установлено только при запуске сервера. Наш опыт в тестировании пула потоков указывает на следующее:

Другая системная переменная, thread_pool_stall_limit, важно для обработки блокированных и продолжительных операторов. Если обо всех вызовах, которые блокируют MySQL Server, сообщают пулу потоков, он всегда знал бы, когда потоки выполнения блокируются. Однако, это, возможно, всегда не истина. Например, блоки могли произойти в коде, который не был инструментован с обратными вызовами пула потоков. Для таких случаев пул потоков должен быть в состоянии идентифицировать потоки, которые, кажется, блокируются. Это делается посредством тайм-аута, длина которого может быть настроена, используя thread_pool_stall_limit системная переменная. Этот параметр гарантирует, что сервер не становится полностью блокированным. Значение thread_pool_stall_limit имеет верхний предел 6 секунд, чтобы предотвратить риск заведенного в тупик сервера.

thread_pool_stall_limit также позволяет пулу потоков обработать продолжительные операторы. Если бы продолжительному оператору разрешили блокировать группу потока, то все другие соединения, присвоенные группе, были бы блокированы и неспособны запустить выполнение до продолжительного завершенного оператора. В худшем случае это могло занять часы или даже дни.

Значение thread_pool_stall_limit должен быть выбран так, что операторы, которые выполняются дольше, чем его значение считают остановленным. Остановленные операторы генерируют много дополнительных издержек, так как они включают дополнительные контекстные переключения и в некоторых случаях даже дополнительные создания потока. С другой стороны, установка thread_pool_stall_limit параметр слишком высоко означает, что продолжительные операторы блокируют много коротко рабочих операторов для дольше чем необходимый. Короткий ожидают потоки разрешения на значения, чтобы запуститься более быстро. Короткие значения также лучше для ухода от ситуаций с мертвой блокировкой. Значения долгого ожидания полезны для рабочих нагрузок, которые включают продолжительные операторы, чтобы избежать запускать слишком много новых операторов, в то время как текущие выполняются.

Предположите, что сервер выполняет рабочую нагрузку, где 99.9 % операторов завершается в пределах 100 мс, даже когда сервер загружается, и остающиеся операторы берут между 100 мс и 2 часа справедливо равномерно распространение. В этом случае имело бы смысл устанавливать thread_pool_stall_limit к 10 (значение 100 мс). Значение по умолчанию 60 мс хорошо для серверов, которые прежде всего выполняют очень простые операторы.

thread_pool_stall_limit параметр может быть изменен во времени выполнения, чтобы позволить Вам ударить баланс, подходящий для рабочей нагрузки сервера. Принятие, что TP_THREAD_GROUP_STATS таблица включается, можно использовать следующий запрос, чтобы определить часть выполняемых операторов, которые остановились:

SELECT SUM(STALLED_QUERIES_EXECUTED) / SUM(QUERIES_EXECUTED)FROM information_schema.TP_THREAD_GROUP_STATS;

Это число должно быть настолько низким насколько возможно. Чтобы уменьшить вероятность остановки операторов, увеличьте значение thread_pool_stall_limit.

Когда оператор прибывает, каково максимальное время, это может быть задержано прежде, чем это фактически начнет выполняться? Предположите, что следующие условия применяются:

В худшем случае 10 высокоприоритетных операторов представляют 10 транзакций, которые продолжают выполняться в течение долгого времени. Таким образом, в худшем случае, никакие операторы не будут перемещены к высокоприоритетной очереди, потому что это будет всегда уже содержать операторы, ждущие выполнения. После 10 секунд новый оператор имеет право быть перемещенным к высокоприоритетной очереди. Однако, прежде, чем это может быть перемещено, все операторы прежде, чем это должно будет быть перемещено также. Это могло занять еще 2 секунды, потому что максимум 100 операторов в секунду перемещается к высокоприоритетной очереди. Теперь, когда оператор достигает высокоприоритетной очереди, могло потенциально быть много продолжительных операторов перед этим. В худшем случае каждые из тех станут остановленными, и потребуется 1 секунда для каждого оператора прежде, чем следующий оператор будет получен от высокоприоритетной очереди. Таким образом, в этом сценарии, это возьмет за 222 секунды до того, как новый оператор начинает выполняться.

Этот пример показывает худший случай для приложения. То, как обработать это, зависит от приложения. Если у приложения есть высокие требования в течение времени отклика, оно должно наиболее вероятно отрегулировать пользователей в более высоком уровне непосредственно. Иначе, это может использовать параметры конфигурации пула потоков, чтобы установить некоторое максимальное время ожидания.