thread_pool_algorithm: Алгоритм конкурентности для планирования.

thread_pool_dedicated_listeners: Назначает поток-слушатель в каждой группе потоков для прослушивания входящих заявок от подключений, назначенных этой группе.

thread_pool_high_priority_connection: Способ планирования выполнения запросов для сеанса.

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

thread_pool_max_active_query_threads: Количество активных потоков в группе.

thread_pool_max_transactions_limit: Максимальное количество транзакций, разрешенное плагином пула потоков.

thread_pool_max_unused_threads: Количество разрешенных спящих потоков.

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

thread_pool_query_threads_per_group: Количество потоков запросов, разрешенных в группе потоков (по умолчанию один поток запросов). Рассмотрите возможность увеличения значения, если вы наблюдаете замедление времени отклика из-за длительных транзакций.

thread_pool_size: Количество групп потоков в пуле. Это самый важный параметр, контролирующий производительность пула потоков.

thread_pool_stall_limit: Время, через которое выполняемый запрос считается зависшим.

thread_pool_transaction_delay: Период задержки перед запуском новой транзакции.

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

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

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

Настройка thread_pool_transaction_delay не влияет на запросы, выпущенные с привилегированного подключения (подключение, назначенное группе потоков Admin). Эти запросы не подпадают под действие настроенной задержки транзакции.

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

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

При запуске плагина пула потоков он создает один поток на группу (поток-прослушиватель) плюс фоновый поток. Дополнительные потоки создаются по мере необходимости для выполнения запросов.

Значение системной переменной thread_pool_stall_limit определяет значение выражения «завершается быстро» в предыдущем пункте. По умолчанию время, прежде чем потоки считаются приостановленными, составляет 60 мс, но может быть установлено до максимума 6 с. Этот параметр настраивается, чтобы вы могли найти баланс, подходящий для рабочей нагрузки сервера. Короткие значения ожидания позволяют потокам начинать работу быстрее. Короткие значения также лучше для предотвращения тупиковых ситуаций. Длинные значения ожидания полезны для рабочих нагрузок, включающих длительные запросы, чтобы избежать запуска слишком большого количества новых запросов, пока выполняются текущие.

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

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

Запрос блокируется, если он сталкивается с операцией ввода-вывода на диск или блокировкой на уровне пользователя (строчная блокировка или табличная блокировка). Блокировка приведет к тому, что группа потоков станет неиспользуемой, поэтому есть обратные вызовы в пул потоков, чтобы гарантировать, что пул потоков может немедленно запустить новый поток в этой группе для выполнения другого запроса. Когда заблокированный поток возвращается, пул потоков позволяет ему немедленно перезапуститься.

Существуют две очереди: очередь высокой приоритетности и очередь низкой приоритетности. Первый запрос в транзакции попадает в очередь низкой приоритетности. Любые последующие запросы для транзакции попадают в очередь высокой приоритетности, если транзакция активна (запросы для нее уже начали выполняться), или в очередь низкой приоритетности в противном случае. Назначение очереди может быть изменено путем включения системной переменной thread_pool_high_priority_connection, которая заставляет все запросы в очереди для сессии попадать в очередь высокой приоритетности.

Запросы для нетранзакционного хранилища или транзакционного хранилища, если включена переменная autocommit, обрабатываются как запросы низкой приоритетности, поскольку в этом случае каждый запрос является транзакцией. Таким образом, при смешанном выполнении запросов для таблиц InnoDB и MyISAM пул потоков отдаёт приоритет запросам для таблиц InnoDB над запросами для таблиц MyISAM, если не включена переменная autocommit. При включенной autocommit все запросы имеют низкий приоритет.

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

Если запрос находится в очереди низкой приоритетности слишком долго, пул потоков перемещает его в очередь высокой приоритетности. Значение системной переменной thread_pool_prio_kickup_timer управляет временем перед перемещением. Для каждой группы потоков максимум один запрос за 10 мс (100 за секунду) перемещается из очереди низкой приоритетности в очередь высокой приоритетности.

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

В то время как поток выполняет запрос от пользовательского подключения, инструментирование Performance Schema учитывает активность потока для этого пользовательского подключения. В противном случае Performance Schema учитывает активность для пула потоков.

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

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

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

Запросы с длительным временем выполнения. Они приведут к использованию всех ресурсов только несколькими запросами, и они могут предотвратить доступ всех остальных к серверу.

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

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