введение

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

В качестве примера возьмем продажу билетов на высокоскоростные поезда. Предположим, что каждую секунду необходимо продавать 1000 билетов, а время обработки каждого билета составляет 1 секунду (каждое окно обрабатывает 1 билет в секунду). Тогда в идеале для удовлетворения потребностей необходимо 1000 билетных касс. потребности. Однако ограниченность физических ресурсов делает невозможным создание такого количества окон. В результате покупателям билетов пришлось стоять в очереди. База данных MySQL сталкивается с аналогичными проблемами в сценариях с высоким уровнем параллелизма. Количество ядер ЦП можно сравнить с количеством продавцов билетов. Каждый поток представляет собой окно продажи билетов, а каждая транзакция или запрос соответствует действию покупки билета. По умолчанию MySQL выделяет выделенный поток (окно обработки заявок) для каждого клиентского запроса, но по мере увеличения степени параллелизма этот подход заставляет ЦП выполнять частые переключения контекста, тем самым снижая общую производительность.

Идеи по оптимизации

Чтобы решить эти проблемы, представители Oracle, Percona и MariaDB внедрили механизм пула потоков (Thread Pool). Основная идея пула потоков заключается в том, что вместо назначения выделенного потока для каждого запроса запросы ставятся в очередь и обрабатываются с использованием ограниченных ресурсов потока. Это похоже на ограничение количества билетных касс до разумного диапазона, что позволяет покупателям билетов стоять в очереди, тем самым сокращая потребление частых поездок продавцами билетов.

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

Многоуровневый механизм организации очереди

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

Очередь первого уровня: очередь сетевых запросов.

• Общая очередь запросов：Обработка обычных запросов, которые не находятся в состоянии транзакции.。
• очередь с высоким приоритетом：Обработка запросов, которые уже находятся в статусе транзакции.,Эти запросы будут выполнены в первую очередь после получения.,Не входите в очередь второго уровня.

Очередь второго уровня: очередь рабочих задач.

• очередь запросов：Обработка операций запроса。
• очередь обновлений：Обрабатывать операции обновления данных。
• очередь транзакций：Обработка транзакционных операций。
• Операции управления：нравиться“show”、“set”Подождите, пока операция будет выполнена напрямую,Предположим, что эти операции являются небольшими операциями.

В рамках этого механизма,Очередь запросов первого уровня быстро классифицирует пакет сетевых запросов по типу.,И направьте запрос в соответствующую очередь второго уровня. Каждая очередь в очереди второго уровня может устанавливать уровень параллелизма в зависимости от типа операции.,Используйте это для управления общим количеством потоков,Это предотвращает взаимодействие различных типов операций друг с другом. Если запрос в очереди не обрабатывался в течение определенного периода времени,Вы можете настроить параметры,“thread_pool_stall_limit”чтобы очередь не зависала。

Принципы настройки и оптимизации параметров

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

• thread_pool_oversubscribe：Установите каждыйThread Количество целевых потоков группы.
• thread_pool_normal_weights：Определите целевое соотношение потоков для операций запроса и обновления.。примернравиться,Если соотношение операций запроса и обновления составляет 50:50,И целевое количество потоков - 200,Тогда параллельность каждой операции равна 100.
• thread_pool_trans_weights：Определяет целевое соотношение потоков для транзакционных операций.。
• thread_pool_stall_limit：Установить частоту проверки режима блокировки,Чтобы никакая очередь не зависала надолго.
• thread_pool_size：Определите количество групп потоков,Обычно корректируется в зависимости от конфигурации физических ресурсов.

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

Экспериментальное тестирование

Структура таблицы базы данных： Запустите инструмент Sysbench для создания TPCC. Структура таблицы и исходные данные 1000DW. Конкретные команды следующие:

sysbench /usr/share/sysbench/tpcc.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=yourpassword --mysql-db=tpcc --time=0 --threads=16 --tables=10 --scale=1000 --db-driver=mysql prepare

Загрузка данных： Убедитесь, что в таблице TPCC достаточно данных для моделирования реальной среды с высоким уровнем параллелизма. Первоначальная загрузка данных может занять много времени в зависимости от производительности машины и размера таблицы.

Базовый тест (не оптимизированный)： Проведите базовое тестирование, чтобы получить неоптимизированную производительность. Используйте инструмент Sysbench для моделирования нагрузки при 1000 одновременных подключениях:

sysbench /usr/share/sysbench/tpcc.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=yourpassword --mysql-db=tpcc --time=600 --threads=1000 --tables=10 --scale=1000 --report-interval=10 --db-driver=mysql run

Запишите значения TPS (транзакций в секунду) и TpmC (транзакций в минуту, зафиксированных) в это время.

Тест после оптимизации： Измените конфигурацию MySQL, введите механизм пула потоков с несколькими очередями и повторите описанные выше шаги тестирования:

sysbench /usr/share/sysbench/tpcc.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=yourpassword --mysql-db=tpcc --time=600 --threads=1000 --tables=10 --scale=1000 --report-interval=10 --db-driver=mysql run

• Также запишите значения TPS и TpmC и сравните их с результатами базового теста.
• Расширенное тестирование： Увеличьте количество одновременных подключений до 3000 и понаблюдайте за производительностью оптимизированного пула потоков при более высокой одновременной нагрузке:

sysbench /usr/share/sysbench/tpcc.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=yourpassword --mysql-db=tpcc --time=600 --threads=3000 --tables=10 --scale=1000 --report-interval=10 --db-driver=mysql run

Снова запишите значения TPS и TpmC, чтобы проанализировать стабильность и время отклика системы в условиях высокого параллелизма.

Результат использования «показать статус типа «thread%»» для просмотра количества потоков:

mysql> show status like 'thread%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Threadpool_idle_threads | 31    |
| Threadpool_threads      | 179   |
| Threadpool_wait_threads | 23    |
| Threads_cached          | 0     |
| Threads_connected       | 1001  |
| Threads_created         | 179   |
| Threads_running         | 172   |
+-------------------------+-------+

В случае 1000 одновременных подключений всего создается 179 потоков для обслуживания этих клиентских подключений, количество транзакций в секунду (TPS) составляет около 5000, а значение TpmC — около 80 000.

Далее используйте для тестирования 3000 одновременных подключений. Результаты следующие:

mysql> show status like 'thread%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Threadpool_idle_threads | 32    |
| Threadpool_threads      | 179   |
| Threadpool_wait_threads | 24    |
| Threads_cached          | 0     |
| Threads_connected       | 3001  |
| Threads_created         | 179   |
| Threads_running         | 172   |
+-------------------------+-------+

Когда количество одновременных подключений увеличилось до 3000, количество потоков осталось неизменным и не увеличилось. Оно по-прежнему составляло 179 потоков. Значение TpmC также оставалось на отметке 80 000, что указывает на отсутствие потери TPS.

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

Применимые сценарии и ограничения

Хотя оптимизированные пулы потоков хорошо работают в большинстве сценариев с высоким уровнем параллелизма, в некоторых конкретных случаях они все же имеют ограничения:

1. Сценарии параллелизма больших запросов：нравиться Если одновременно инициируется большое количество долгосрочных больших запросов,Могут накапливаться запросы,Блокируйте небольшие запросы на короткий период времени. Аналогичная ситуация применима и к крупномасштабным операциям обновления. В этом сценарии,Используется ли пул потоков,Производительность базы данных может пострадать,Уровень приложения должен контролировать параллелизм больших запросов.
2. Сценарии с серьезными конфликтами блокировок：Когда параллелизм ожидания блокировки превышает общий параллелизм обработки,Запросы на обработку будут накапливаться,Предотвращает выполнение запросов без блокировок. в это время,Оптимизация прикладного уровня имеет решающее значение.
3. Высококонкурентный запрос подготовленного заявления：При чрезвычайно высоком параллелизме,ИспользоватьMySQL Binary Протокол подготовлен Запросы на запросы могут оказывать давление на процесс прослушивания epoll, особенно в статусе транзакции. Это может привести к тому, что обычные запросы не будут выполнены вовремя в очереди первого уровня.
4. блокировка очереди：Когда запросы на операции определенного типа накапливаются до определенного уровня,Когда он не обрабатывался в течение длительного времени,Может повлиять на общую производительность системы。Можно регулировать с помощью“thread_pool_stall_limit”параметры для решения этой проблемы。

Подвести итог

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