Назад | Перейти на главную страницу

Добавление процессоров снижает производительность MySQL 5.5 (Debian)

Я собираюсь настроить сервер базы данных (MySQL) в контейнере OpenVZ, и мне было интересно, сколько процессоров я должен ему назначить. Я решил протестировать его. Я сравнил два дистрибутива OS / MySQL и проверил, как они работают с 1, 2, 3 и 4 процессорами.

Первая конфигурация программного обеспечения была:

Второй:

Оба были запущены на одном ядре - 2.6.32-openvz-042stab083.2-amd64 # 1 SMP Пт 8 ноября 17:59:25 MSK 2013 x86_64 GNU / Linux.

Все программное обеспечение было установлено из пакетов и использовалось сразу после установки без какой-либо настройки конфигурации.

Оборудование: 6 ГБ ОЗУ, 1-4 процессора 3,5 ГГц.

Для тестирования я использовал sysbench со следующим сценарием:

sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --db-driver=mysql --mysql-password=d prepare
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --db-driver=mysql --mysql-password=d --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run

В обоих случаях движком таблицы был InnoDB.

Результатом, на который я смотрел, было количество транзакций в секунду. Результаты были достаточно стабильными - ошибка менее 1%.

Результаты были хорошими и ожидаемыми для CentOS / MySQL5.1, но очень странными для Debian / MySQL5.5:

Как видите, MySQL5.5 в Debian не может должным образом использовать преимущества нескольких процессоров. Хотя производительность с двумя процессорами выше, чем с одним, она явно ниже, чем с CentOS / MySQL5.1. Более того, он снижается, когда мы добавляем больше процессоров поверх двух, что действительно странно.

Может кто-нибудь объяснить, что там происходит? Почему MySQL будет работать хуже, если мы добавим процессоры?

Чтобы не лопнуть чей-то пузырь догадок, но это ошибка в MySQL 5.5.

Ну, это действительно наводящий вопрос, если вы не знаете что-то об архитектуре, которую вы используете ... но обычно наблюдается экспоненциальный удар по пропускной способности шины при добавлении мощности ЦП, особенно архитектуры, которая поддерживает несколько многоядерных процессоров, просто остановитесь и подумайте на мгновение последствия для цикла прерывания при любом развернутом ограничении пропускной способности шины .... в любом случае производительности ... понимание того, что ваша архитектура будет либо узким местом ввода-вывода, либо битами за цикл, снова имейте в виду, что для нескольких процессоров требуется многопоточность .. так что независимо от скорости вашей системной шины ... если у вас только 64-битное оборудование, то физическое электрическое соединение должно будет разделить это ограничение на столько же ядер в одном тактовом цикле ... теперь остановитесь и подумайте положительных последствий перехода с 64-битной на 256-битную системную плату, вы можете получить в 3 раза лучшую пропускную способность при полном наклоне, учитывая, что x1 будет потрачен на многопоточность / поддержку Opera накладные расходы .. однако во время обычных операций вы можете столкнуться с неприятной реальностью, связанной с накладными расходами, когда вам нужен только один процессор / оператор .. Я думаю, это балансирующее действие или, точнее говоря, правильная лошадь для правильного курса .. Steveo Reedo nextfriend @ live.co.uk

Когда вы добавляете процессоры, он будет выполнять больше операций параллельно. Если вы не увеличили количество ОЗУ, тогда может произойти подкачка, особенно если вы используете более толстую (а более новая в основном означает более толстую) версию тестируемого программного обеспечения.