8.11.5.1. Как MySQL Uses Threads for Client Connections

Потоки менеджера соединений обрабатывают клиентские запросы соединения на сетевых интерфейсах, которые слушает сервер. На всех платформах один поток менеджера обрабатывает запросы соединения TCP/IP. На Unix этот поток менеджера также обрабатывает запросы соединения файла сокета Unix. На Windows поток менеджера обрабатывает запросы сопряжения с общей памятью, и другое соединение именованного канала дескрипторов запросы. Сервер не создает потоки, чтобы обработать интерфейсы, которые он не слушает. Например, Windows server, у которого нет поддержки соединений именованного канала включенной, не создает поток, чтобы обработать их.

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

В этой модели потока соединения есть так много потоков, как есть клиенты, в настоящий момент соединенные, у которого есть некоторые недостатки, когда рабочая нагрузка сервера должна масштабироваться, чтобы обработать большие количества соединений. Например, создание потока и распоряжение становятся дорогими. Кроме того, каждый поток требует сервера и ресурсов ядра, таких как стековое пространство. Чтобы разместить большое количество одновременных соединений, размер стека на поток должен быть сохранен маленьким, приводя к ситуации, где это является или слишком маленьким или сервер, использует большие объемы памяти. Исчерпание других ресурсов может произойти также, и издержки планирования могут стать существенными.

С MySQL 5.6.10 коммерческие дистрибутивы MySQL 5.6 включают плагин пула потоков, который обеспечивает альтернативную обрабатывающую поток модель, разработанную, чтобы уменьшить издержки и улучшить производительность. Это реализует пул потоков, который увеличивает производительность сервера, эффективно управляя потоками выполнения оператора для больших количеств клиентских соединений. См. Раздел 8.11.6, "Плагин Пула потоков".

Чтобы управлять и контролировать, как сервер управляет потоками, которые обрабатывают клиентские соединения, несколько систем и переменных состояния релевантны. (См. Раздел 5.1.4, "Системные Переменные Сервера", и Раздел 5.1.6, "Переменные Состояния Сервера".)

Кэшу потока определили размер thread_cache_size системная переменная. Значение по умолчанию 0 (никакое кэширование), который заставляет поток быть установленным для каждого нового соединения и избавленным, когда соединение завершается. Набор thread_cache_size к N включать N неактивное соединение распараллеливает, чтобы кэшироваться. thread_cache_size может быть установлен при запуске сервера или изменен, в то время как сервер работает. Поток соединения становится неактивным, когда клиентское соединение, с которым он был связан, завершается.

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

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

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