8.11.6.2. Работа Пула потоков

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

Число групп потока является конфигурируемым использованием thread_pool_size системная переменная. Число значения по умолчанию групп 16. Для направляющих линий при установке этой переменной см. Раздел 8.11.6.3, "Настройка Пула потоков".

Максимальное количество потоков на группу 4096 (или 4095 на некоторых системах, где один поток используется внутренне).

Пул потоков разделяет соединения и потоки, таким образом нет никакого фиксированного отношения между соединениями и потоками, которые выполняют операторы, полученные от тех соединений. Это отличается от модели обработки потока значения по умолчанию, которая связывает один поток с одним соединением так, что, поток выполняет все операторы от соединения.

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

Каждая группа потока сделала, чтобы слушатель распараллелил, который прислушивается к входящим операторам от соединений, присвоенных группе. Когда оператор прибывает, группа потока или начинает выполнять ее сразу или ставит ее в очередь для более позднего выполнения:
- Непосредственное выполнение происходит, если оператор является единственным полученным, и никакие операторы не ставятся в очередь или в настоящий момент выполнение.
- Организация очередей происходит, если оператор не может начать выполняться сразу.
Если непосредственное выполнение происходит, выполнение выполняется потоком слушателя. (Это означает, что временно никакой поток в группе не слушает.), Если оператор заканчивается быстро, выполняющийся поток возвращается к прислушиванию к операторам. Иначе, пул потоков считает оператор остановленным и запускает другой поток как поток слушателя (создающий это в случае необходимости). Чтобы гарантировать, что никакая группа потока не становится блокированной остановленными операторами, у пула потоков есть фоновый поток, который регулярно контролирует групповые состояния потока.

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

Когда плагин пула потоков запускается, он создает один поток на группу (поток слушателя) плюс фоновый поток. Дополнительные потоки создаются по мере необходимости, чтобы выполнить операторы.
Значение thread_pool_stall_limit системная переменная определяет значение "концов быстро" в предыдущем элементе. Время значения по умолчанию перед потоками считают остановленным, 60 мс, но могут быть установлены в максимум 6s. Этот параметр конфигурируем, чтобы позволить Вам ударить баланс, подходящий для рабочей нагрузки сервера. Короткий ожидают потоки разрешения на значения, чтобы запуститься более быстро. Короткие значения также лучше для ухода от ситуаций с мертвой блокировкой. Значения долгого ожидания полезны для рабочих нагрузок, которые включают продолжительные операторы, чтобы избежать запускать слишком много новых операторов, в то время как текущие выполняются.
Пул потоков сосредотачивается на том, чтобы ограничивать число параллельных коротко рабочих операторов. Прежде, чем выполняющийся оператор достигает времени останова, он препятствует тому, чтобы другие операторы начали выполняться. Если оператор выполняется мимо времени останова, ему разрешают продолжаться, но больше не препятствует тому, чтобы другие операторы запустились. Таким образом пул потоков пытается гарантировать что в каждой группе потока никогда нет чем один коротко рабочий оператор, хотя могли бы быть многократные продолжительные операторы. Это - нежелательный, чтобы позволить продолжительным операторам препятствовать тому, чтобы другие операторы выполнились, потому что нет никакого предела на количестве ожидания, которое могло бы быть необходимым. Например, на ведущем устройстве репликации, поток, который отправляет двоичные события журнала ведомому устройству эффективно, работает навсегда.
Оператор становится блокированным, если он встречается с дисковой работой ввода-вывода или пользовательской блокировкой уровня (блокировка строки или блокировка таблицы). Блок заставил бы группу потока становиться неиспользованной, таким образом есть обратные вызовы к пулу потоков, чтобы гарантировать, что пул потоков может сразу начать новую дискуссию в этой группе, чтобы выполнить другой оператор. Когда блокированный поток возвращается, пул потоков разрешает этому сразу перезапустить.
Есть две очереди, высокоприоритетная очередь и низкоприоритетная очередь. Первый оператор в транзакции идет к низкоприоритетной очереди. Любой после операторов для транзакции идет к высокоприоритетной очереди, если транзакция является продолжающейся (операторы для этого начали выполняться), или низкоприоритетной очереди иначе. На присвоение очереди можно влиять, включая thread_pool_high_priority_connection системная переменная, которая заставляет все операторы с очередями для сеанса входить в высокоприоритетную очередь.

Операторы для нетранзакционного механизма хранения, или транзакционного механизма, если autocommit включается, обрабатываются как низкоприоритетные операторы, потому что в этом случае каждый оператор является транзакцией. Таким образом, учитывая соединение операторов для InnoDB и MyISAM таблицы, пул потоков располагает по приоритетам тех для InnoDB по тем для MyISAM если autocommit включается. С autocommit включенный, все операторы будут низким приоритетом.
Когда группа потока выбирает оператор с очередями для выполнения, это сначала смотрит в высокоприоритетной очереди, затем в низкоприоритетной очереди. Если оператор находится, он удаляется из его очереди и начинает выполняться.
Если оператор остается в низкоприоритетной очереди слишком долго, пул потоков перемещается к высокоприоритетной очереди. Значение thread_pool_prio_kickup_timer системная переменная управляет временем перед перемещением. Для каждой группы потока максимум одного оператора на 10 мс или 100 в секунду будет перемещен от низкоприоритетной очереди к высокоприоритетной очереди.
Пул потоков снова использует самые активные потоки, чтобы получить намного лучшее использование кэшей ЦП. Это - маленькая корректировка, у которой есть огромное влияние на производительность.
В то время как поток выполняет оператор от пользовательского соединения, действия потока учетных записей инструментария Схемы Производительности к пользовательскому соединению. Иначе, Схема Производительности считает действие к пулу потоков.

Вот примеры условий, при которых группе потока можно было бы запустить многократные потоки, чтобы выполнить операторы:

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

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

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

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

Максимальное количество потоков, которые могут произойти, является суммой max_connections и thread_pool_size. Это может произойти в ситуации, где все соединения находятся в режиме выполнения, и дополнительный поток создается на группу, чтобы прислушаться к большему количеству операторов. Это - не обязательно состояние, которое часто происходит, но это теоретически возможно.