Amazon RDS - max_connections

Question

Мой простой вопрос: Как увеличить возможное количество соединений моей базы данных Amazon RDS? я использовал параметр группу, где я установить

max_connections = 30000 

, который, кажется, работает на первой руке, а

SHOW VARIABLES LIKE 'max_connections'; 

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

Моя установка теста: 1 Load Balancer 8 жира экземпляров EC2 (m4.4xlarge) (который немного overdimensioned, но я до сих пор тестирование) 1 DB: r3.4xlarge с памятью 140 ГБ, 1 ТБ хранение и 10.000 подготовленных IOPS

Тест: 30 000 виртуальных пользователей за 10 минут делают по 4 запроса каждый (2 считывают БД, 1 записывают его, 1 не используют БД). Не работает через две минуты из-за слишком большого количества ошибок (вызванных таймаутами БД).

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

Answer 1

Я бы настоятельно сказал, что первая проблема связана не с конфигурацией сервера, а с вашей методологией тестирования и интерпретацией того, что вы видите.

Удар max_connections вначале не вызывает «тайм-ауты db». Это вызывает ошибки подключения, поскольку сервер активно отклоняет чрезмерные попытки подключения, отказавшись от переговоров. Это не то же самое, что время ожидания.

В какой момент, во время какой операции происходят таймауты? Начальная фаза подключения? Это не будет связано с max_connections, по крайней мере, не напрямую.

Максимальное количество подключений, которые вы наблюдаете, похоже на подозрительно круглое число и потенциально даже выводится из ваших тестовых параметров ... Вы упомянули 30000 пользователей и 10 минут и 4 заявки ... и 30000 × 4 & divide; 10 & divide; 10 = 1200. Да, я бросил «10» дважды без особых причин, кроме 1200, просто кажется очень подозрительным. Интересно, будет ли, если вы используете 15000 пользователей, число будет снижаться с 1200 до 600. Это было бы интересно исследовать.

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

Не менее важно, что 30000 подключений к одному серверу MySQL независимо от размера кажется полностью отделенным от реальности, кроме возможно с пулом потоков, который недоступен в версии MySQL, используемой в RDS. Если бы вы успешно создали это множество подключений, на холодном сервере или без массивного потока, уже разогретый кеш, скорее всего, потребуется несколько минут, чтобы ОС разрешила MySQL создавать много новых потоков.Вы действительно видите таймауты здесь, потому что ОС не позволит серверу не отставать от входящего спроса, но он не будет связан с max_connections.

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

Answer 2

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

Все мои восемь экземпляров EC2 были ограничены MaxRequestWorkers = 150 (-> 8 * 150 = 1200). Что очевидно для каждого праздника, администратор занял у меня день. По крайней мере, все работает сейчас.