Справочное руководство по MySQL версии 4.1.1-alpha




2.6.1 Примечания к Linux (Все версии Linux) - часть 4


При тестировании MySQL на двухпроцессорной машине с ядром 2.4 мы обнаружили, что MySQL масштабируется гораздо лучше - фактически отсутствовало замедление обработки запросов вплоть до 1000 соединений, а фактор масштабируемости MySQL (который вычисляется как отношение максимальной производительности к производительности при работе с одним клиентом) достигал 180%. Подобные результаты мы наблюдали на четырехпроцессорной системе - фактическое отсутствие замедления при росте количества соединений до 1000 при факторе масштабируемости в 300%. Поэтому для интенсивно нагруженных серверов мы настоятельно рекомендуем ядро 2.4. Оказалось также, что для достижения максимума производительности на ядре 2.4 весьма важно запускать mysqld с наибольшим возможным приоритетом. Для этого следует добавить в скрипт safe_mysqld команду renice -20 $$. В наших тестах на четырехпроцессорной машине увеличение приоритета привело к повышению производительности на 60% при работе 400 клиентов.

В дополнение к этому мы сейчас занимаемся сбором информации о производительности MySQL с ядром 2.4 на четырех- и восьмипроцессорных системах. Если у вас есть доступ к таким системам и вы тестировали их производительность, пожалуйста, отправьте сообщение с результатами по адресу docs@mysql.com - мы добавим эти результаты в документацию.

Существует еще один нюанс, заметно влияющий на производительность

MySQL, особенно на многопроцессорных системах. В LinuxThreads в glibc-2.1 очень плохо реализованы mutex'ы для программ со множеством потоков, в которых mutex хранится непродолжительное время. Парадоксально, но факт: в случае, если на многопроцессорных системах собрать MySQL с немодифицированными LinuxThreads, то при удалении процессора во много раз увеличивается производительность. Для решения этой проблемы мы предлагаем патч к glibc 2.1.3 http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch.

В glibc-2.2.2 MySQL версии 3.23.36 использует адаптивный mutex, который гораздо лучше даже ``патченного'' в glibc-2.3.1. Однако предупреждаем, что при некоторых условиях код mutex'а в glibc-2.2.2 "закручивается" (overspin), а это ухудшает производительность MySQL. Шансы возникновения такого события можно понизить, если повысить приоритет выполнения mysqld. Можно также исправить "закручивание" с помощью патча, доступного по адресу http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. Он содержит в себе коррекцию "закручивания", максимальное количество потоков и размеры стека - все вместе. Необходимо применить его в каталоге linuxthreads




Содержание  Назад  Вперед