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

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

Другая системная переменная, thread_pool_stall_limit, важна для обработки заблокированных и длительно выполняемых запросов. Если все вызовы, блокирующие MySQL Server, передаются в пул потоков, то он всегда будет знать, когда потоки выполнения заблокированы. Однако это не всегда верно. Например, блокировки могут происходить в коде, не снабжённом вызовами обратного вызова пула потоков. В таких случаях пул потоков должен уметь определять потоки, которые, похоже, заблокированы. Это делается с помощью таймаута, который можно настроить, используя системную переменную thread_pool_stall_limit, значение которой измеряется в 10-миллисекундных единицах. Этот параметр гарантирует, что сервер не заблокируется полностью. Значение 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 можно изменить во время выполнения, чтобы найти оптимальное значение для рабочей нагрузки сервера. Предполагая, что таблица 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 секунды, прежде чем новый запрос начнёт выполняться.

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