Spec-Zone .ru
спецификации, руководства, описания, API

8.11.5.1. Как MySQL Uses Threads for Client Connections

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

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

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

Чтобы управлять и контролировать, как сервер управляет потоками, которые обрабатывают клиентские соединения, несколько систем и переменных состояния релевантны. (См. Раздел 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.