Mysql с несколькими процессорами и мульти сридингом

[Skyb]

Было замечено что про большой нагрузке мускула использовался только 1 процессор на 100 процентов. Как реализовать в мускуле поддержку всех процессоров
uname - a

Код: Выделить всё

Linux localhost 2.6.31.12-server-3mnb #1 SMP Thu Mar 25 13:24:49 EDT 2010 x86_64 Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz GNU/Linux

mysql -V

Код: Выделить всё

mysql  Ver 14.14 Distrib 5.1.42, for mandriva-linux-gnu (x86_64) using readline 6.0

[neol]

Сколько ему надо, столько и использует. Если нужно будет одновременно выполнять несколько тяжелых запросов, то поток может быть перекинут на свободный процессор (но этим займется ядро, а не mysql).

[Skyb]

Сколько ему надо, столько и использует. Если нужно будет одновременно выполнять несколько тяжелых запросов, то поток может быть перекинут на свободный процессор (но этим займется ядро, а не mysql).

Хех, неправильно рассуждаете ну либо (хотя наврятли) у меня ядро без поддержки много процесорности
внизу скрин как можно забить мускул и он не перекинет на друго йпроцессор

[neol]

В настройках htop добавьте отображение колонки PROCESSOR, включите отображение потоков (threads) и почитайте насчет работы планировщика - http://oreilly.com/catalog/linuxkernel/chapter/ch10.html Думаю станет понятно, почему основная нагрузка ложится на одно ядро. Хотя mysql действительно не очень хорошо чувствует себя на многопроцессорных конфигурациях.

[Skyb]

В настройках htop добавьте отображение колонки PROCESSOR, включите отображение потоков (threads) и почитайте насчет работы планировщика - http://oreilly.com/catalog/linuxkernel/chapter/ch10.html Думаю станет понятно, почему основная нагрузка ложится на одно ядро. Хотя mysql действительно не очень хорошо чувствует себя на многопроцессорных конфигурациях.

Эм, а не могли бы разъяснить, а то что то понимание пока что не приходить
Был бы признателен

[neol]

Сразу предупреждаю, что я не достаточно хорошо разбираюсь и в ядре, и в mysql (: Да и продолжительное отсутствие сна не благоприятствует мыслительному процессу.
Насколько я понимаю ситуацию, планировщик переносит поток на другое ядро только в том случае, когда он(поток) ожидает выполнения дольше, чем требуется на заполнение кеша процессора, дабы избежать излишних расходов на эту операцию (это в общем-то вполне логично). Соответственно кучка мелких запросов, которые выполняются меньше этого времени, выполняются друг за другом, на том ядре, на котором выполнялся поток до этого (емнип mysql использует некий пул потоков). Теоретически, это не должно вызывать ощутимого падения производительности, но где-то в сети проскакивали тесты, в которых mysql показывал падение производительности при переходе от 4 к 8 ядрам, да и в багтреке mysql есть подобный вашему топик.
Если у вас наблюдается падение производительности в моменты пиковой нагрузки, возможно даст положительный эффект увеличение thread_concurrency (тут прошу обратить внимание на первую строчку поста), но лучше будет полистать на досуге high performance mysql, возможно там есть рекомендации по этому поводу, которые я пропустил или просто забыл.
Так-же можно поэкспериментировать с chrt (возможно taskset), но не на рабочем сервере и эффект от этого действия сомнителен.

PS Есть мнение, что топику место в Администрировании.

[Skyb]

Сразу предупреждаю, что я не достаточно хорошо разбираюсь и в ядре, и в mysql (: Да и продолжительное отсутствие сна не благоприятствует мыслительному процессу.
Насколько я понимаю ситуацию, планировщик переносит поток на другое ядро только в том случае, когда он(поток) ожидает выполнения дольше, чем требуется на заполнение кеша процессора, дабы избежать излишних расходов на эту операцию (это в общем-то вполне логично). Соответственно кучка мелких запросов, которые выполняются меньше этого времени, выполняются друг за другом, на том ядре, на котором выполнялся поток до этого (емнип mysql использует некий пул потоков). Теоретически, это не должно вызывать ощутимого падения производительности, но где-то в сети проскакивали тесты, в которых mysql показывал падение производительности при переходе от 4 к 8 ядрам, да и в багтреке mysql есть подобный вашему топик.
Если у вас наблюдается падение производительности в моменты пиковой нагрузки, возможно даст положительный эффект увеличение thread_concurrency (тут прошу обратить внимание на первую строчку поста), но лучше будет полистать на досуге high performance mysql, возможно там есть рекомендации по этому поводу, которые я пропустил или просто забыл.
Так-же можно поэкспериментировать с chrt (возможно taskset), но не на рабочем сервере и эффект от этого действия сомнителен.

PS Есть мнение, что топику место в Администрировании.

Да согласен что в администрирование, просто думал особенности системы возможно важны

[Skyb]

Вопрос снимается, эта версия мускула многопроцессорная! но, для каждого запроса выделяется 1 процессор-тоесть нельзя распаралелить 1 запрос на несколько процов (почемуто сразу не проверил )

[SinClaus]

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

[Skyb]

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

Кстати - это довольно заманчивая перспектива, потому как я у меня парой в отчетах такие запросы %) выполнение происходит по минут 20--30, это отчет по коэффициенту мультиплексирования