7.1.12.1 Connection Interfaces — MySQL 8.4

7.1.12.1 Интерфейсы подключений

В данном разделе описываются аспекты управления подключениями клиентов к серверу MySQL.

Сетевые интерфейсы и потоки менеджера подключений

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

На всех платформах один поток менеджера обрабатывает запросы на подключение TCP/IP.
В Unix тот же поток менеджера также обрабатывает запросы на подключение через Unix-сокеты.
В Windows один поток менеджера обрабатывает запросы на подключение через общую память, а другой — через именованные каналы.
На всех платформах может быть включен дополнительный сетевой интерфейс для приема запросов на администрирование подключений по TCP/IP. Этот интерфейс может использовать поток менеджера, обрабатывающий «обычные» запросы TCP/IP, или отдельный поток.

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

Отдельные плагины или компоненты сервера могут реализовывать собственные интерфейсы подключения:

Плагин X позволяет серверу MySQL общаться с клиентами, используя протокол X. См. Раздел 22.5, «Плагин X».

Управление потоками подключения клиентов

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

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

MySQL Enterprise Edition включает плагин пула потоков, который предоставляет альтернативную модель обработки потоков, предназначенную для уменьшения накладных расходов и повышения производительности. Он реализует пул потоков, который повышает производительность сервера, эффективно управляя потоками выполнения инструкций для большого числа подключений клиентов. См. Раздел 7.6.3, «MySQL Enterprise Thread Pool».

Для управления и мониторинга того, как сервер управляет потоками, обрабатывающими подключения клиентов, применимы несколько системных и статусных переменных. (См. Раздел 7.1.8, «Системные переменные сервера» и Раздел 7.1.10, «Статусные переменные сервера».)

Системная переменная thread_cache_size определяет размер кэша потоков. По умолчанию сервер автоматически настраивает значение при запуске, но его можно явно задать, чтобы переопределить это значение по умолчанию. Значение 0 отключает кэширование, что приводит к созданию потока для каждого нового подключения и его удалению при завершении подключения. Чтобы включить N кэширование неактивных потоков подключений, установите thread_cache_size на N при запуске сервера или во время выполнения. Поток подключения становится неактивным, когда завершается подключение клиента, с которым он был связан.
Чтобы отслеживать количество потоков в кэше и количество потоков, которые были созданы, потому что поток не мог быть взят из кэша, проверьте статусные переменные Threads_cached и Threads_created.
Когда стековая память потока слишком мала, это ограничивает сложность SQL-запросов, которые может обрабатывать сервер, глубину рекурсии хранимых процедур и другие действия, потребляющие много памяти. Чтобы установить размер стека в N байт для каждого потока, запустите сервер с thread_stack, установленным на N.

Управление объемом подключений

Чтобы контролировать максимальное количество клиентов, которые сервер разрешает подключиться одновременно, установите системную переменную max_connections при запуске сервера или во время его работы. Может потребоваться увеличить max_connections, если больше клиентов пытаются подключиться одновременно, чем сервер настроен обработать (см. Раздел B.3.2.5, «Слишком много подключений»). Если сервер отклоняет подключение, потому что предел max_connections достигнут, он увеличивает значение статусной переменной Connection_errors_max_connections.

mysqld фактически разрешает max_connections + 1 подключение клиента. Дополнительное подключение резервируется для использования учетными записями, имеющими привилегию CONNECTION_ADMIN (или устаревшую привилегию SUPER). Предоставляя привилегию администраторам, а не обычным пользователям (которым она не нужна), администратор может подключиться к серверу и использовать SHOW PROCESSLIST для диагностики проблем, даже если подключено максимальное количество клиентов без привилегий. См. Раздел 15.7.7.31, «Запрос SHOW PROCESSLIST».

Сервер также разрешает административные подключения по административному сетевому интерфейсу, который можно настроить с помощью выделенного IP-адреса и порта. См. Раздел 7.1.12.2, «Управление административными подключениями».

Плагин Group Replication взаимодействует с сервером MySQL с использованием внутренних сеансов для выполнения операций API SQL. Внутренние сеансы Group Replication обрабатываются отдельно от подключений клиентов, поэтому они не учитываются в ограничении max_connections и не отклоняются, если сервер достиг этого ограничения.

Максимальное количество подключений клиентов, которые поддерживает MySQL (то есть максимальное значение, до которого можно установить max_connections), зависит от нескольких факторов:

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

Linux или Solaris, как правило, могут поддерживать как минимум 500–1000 одновременных подключений и до 10 000 подключений, если у вас много гигабайт ОЗУ, а нагрузка от каждого подключения низкая или целевое время отклика невысокое.

Увеличение значения max_connections увеличивает количество дескрипторов файлов, необходимых для mysqld. Если требуемое количество дескрипторов недоступно, сервер уменьшает значение max_connections. Комментарии по ограничениям дескрипторов файлов см. в Разделе 10.4.3.1, «Как MySQL открывает и закрывает таблицы».

Возможно, потребуется увеличить системную переменную open_files_limit, а также, возможно, потребуется увеличить системное ограничение операционной системы на количество дескрипторов файлов, которые может использовать MySQL. Обратитесь к документации вашей операционной системы, чтобы узнать, можно ли увеличить это ограничение и как это сделать. См. также Раздел B.3.2.16, «Файл не найден и аналогичные ошибки».