Здравствуйте
Имеется сервер с 4мя процессорами. На нем линукс (ядро 2.4.21-4.ELsmp), mysql (4.1.8) и апач с php.
Я не администрирую его (да и вообще работаю исключительно с fbsd), но к сожалению администратор болеет, поэтому пришлось мне им заняться. Начались проблемы с загрузкой. Типичная картина, когда mysqld-max грузит ОДИН процессор на 100%, а апач выстраивает очередь на остальных в ожидании обслуживания. Т.е. картина ясна - mysql не желает запускать треды на разных процессорах.
На сайте mysql нашел два замечания касающиеся работы на smp архитектуре и тредов в линуксе.
1. Если "много" (?) процессоров, то нужно сооружать из них кластер (ndbd). Делать этого совсем не хочется.
2. Для реализации тредов в линуксе нужна linuxthread. Однако, как я понимаю, без тредов mysql вообще бы не запустился. Значит библиотека имеется.
Чем же еще можно вылечить эту проблему?
up
up
up
Привет,идеология вкратце такова: MySQL выставляет обработку одного запроса (query) только одному процессору. Если у вас сами запросы проходят тяжело и следуют один за другим, то увеличение количеста процессоров вам ничем не поможет.
То же самое делает и Apache, но поскольку он обрабатывает много запросов паралельно, то успевает разбросать их по отдельным процессорам.
Как минимум, посмотрите статистику вашего SQL сервиса (в mysql консоли выставляем "\s" и списываем последнюю строчку).
WWell,
Выглядит очень логично.
К сожалению (или к счастью), пока что нагрузка не повышалась до критических пределов, поэтому оценку произвести не могу. Пока что так:
Threads: 4 Questions: 59219968 Slow queries: 0 Opens: 16408 Flush tables: 1 Open tables: 256 Queries per second avg: 264.068
Когда наступит overload, сделаю еще раз.
А еще такой момент. До недавнего времени таже база с теми же сайтами крутились на машине с двумя процессорами (в два раза меньше память и тактовая частота). При этом подобной проблемы не возникало. Правда на старой машине был установлен mysql 4.0.18.
При переносе возникли некоторые проблемы. В частности, в синтаксисе sql появились новые ключевые слова, которые до этого использовались как имена полей. Пришлось вносить изменения. Еще были замечены некоторые проблемы с автоинкрементными полями. Но это так - к слову.
Вполне возможно, что подобная обратная несовместимость сказалась и на "тяжести" прохождения некоторых, редко выполняемых, запросов (например анализ статистики посещений - ну очень большие таблицы). Так что есть вероятность, что эту проблемы вызывает всего один "меткий" запрос (и раньше у меня иногда получалось поставить mysql в тупик одним единственным запросом). В таком случае, действительно, параллельным потокам возникать незачем, а загрузка будет в 100%.
Включил протоколирование медленных запросов. Ну и конечно буду смотреть статистику по "\s".
Спасибо за разъяснения!
Привет,> Threads: 4
Т.е. в случмае необходимости и возможности пользуем все 4 процессора...
> Slow queries: 0
Это хорошо, значит все базы у нас проиндексированы как следует.
> Queries per second avg: 264.068
А вот это говорит, что у нас довольно-таки загруженный SQL сервер. Интересно было бы проследить объем баз данных (кол-во записей и количество данных в МВ) и их соотношение са наличной памятью.
WWell,
Привет
>> Slow queries: 0
>
>Это хорошо, значит все базы у нас проиндексированы как следует.да уж старался ;-)
>
>> Queries per second avg: 264.068
>
>А вот это говорит, что у нас довольно-таки загруженный SQL сервер. Интересно
>было бы проследить объем баз данных (кол-во записей и количество данных
>в МВ) и их соотношение са наличной памятью.непотдается учету ;-)
вообще все базы порядка 10G в дампе (по результатам переезда)
всего 12 баз одной структуры (по числу сайтов)
Поскольку там есть и таблицы индексов текстов страниц, статистика посещений (увы - отбиться от ее реализации в виде sql таблицы неудалось - логи апача потребителей не удовлетворяют), сохраненные переменные сеансов, то количество записей сильно разнится в зависимости от размеров статической части сайтов и их популярности. Вот данные по самому посещаемому из них:
Все таблицы поделены на критичные и некритичные в смысле транзакций
некритичные (MyISAM) - 1.1G (здесь вся статистика и прочий мусор)
критичные (InnoDB) - не могу оценить поскольку все в одном файле - как с ним работать не представляю. На все базы 6G
Количество таблиц: 96
Максимальное количество полей: 48
Максимальное количество записей: 6030548 (статистика)
Количество записей в "главной" таблице вокруг которой крутитятся все запросы: 22541
Количество полей в "главной" таблице: 43
Запросы в основном на поиск в "главной" таблице.
Хотя вокруг еще очень много всякой, на мой взгляд ненужной и зачастую невостребованной, чепухи типа протоколирование количества просмотров записей, протоколирование параметров поиска и количества найденых записей. Все это отнимает уйму времени и разобраться что там тормозит больше - mysql или предварительная обработка в php - невозможно. Во всяком случае ZDE в этом слабо помог.
Вообще структура сделана очень криво, поскольку развивалась эволюционным путем методом наложения заплаток в условиях постоянного форсмажера...
Но увы - разработка следующей версии продукта показывает, что и проектирование с нуля с учетом всех требований постановщика задачи (несовместимыми с идеологией sql) не приводит к улучшениям по быстродействию. Во всяком случае в части backoffice. В новой версии данные неструктурированные - в виде xml документов с индексацией по тэгам. Хотя "витрина" получается вроде как быстрой, поскольку состоит из сгенеренных статических фрагментов отображаемых по результатам поиска. Да и сами результаты поиска так же кэшируются.
Привет,>вообще все базы порядка 10G в дампе (по результатам переезда)
А к вмин еще и индексы добавь... вообще, "du -sh" в директории, где хранятся все базы (у меня - /usr/local/var) дает хорошее представление обо всем произходящем. Но при таком количестве данных объем памяти тоже влияет на возможности сервера - ведь SQL engine старается держатя как можно больше из них в памяти...
>Все таблицы поделены на критичные и некритичные в смысле транзакций
>некритичные (MyISAM) - 1.1G (здесь вся статистика и прочий мусор)>критичные (InnoDB) - не могу оценить поскольку все в одном файле -
>как с ним работать не представляю. На все базы 6G
>Количество таблиц: 96
>Максимальное количество полей: 48
>Максимальное количество записей: 6030548 (статистика)При шест миллионах записях - InnoDB действительно лучше.
Кажется, что вы выжали более-менее то, что можно было выжать в смысле performance... Дальше идут только хитрости типа тьюнинга ядра и самого MySQL, но недумаю, что это в состоянии резко улучшить ситуацию.
Привет>А к вмин еще и индексы добавь... вообще, "du -sh" в директории,
>где хранятся все базы (у меня - /usr/local/var) дает хорошее представление
>обо всем произходящем. Но при таком количестве данных объем памяти тожеНе, я имел ввиду, что все таблицы innodb хранятся в файле заранее зарезервированного размера (tablespace). Нечто вроде собственной файловой системе. Так вот непонятно как там смотреть сколько под какие таблицы занято.
>влияет на возможности сервера - ведь SQL engine старается держатя как
>можно больше из них в памяти...2G. Правда занято почти все.
>Кажется, что вы выжали более-менее то, что можно было выжать в смысле
>performance... Дальше идут только хитрости типа тьюнинга ядра и самого MySQL,
>но недумаю, что это в состоянии резко улучшить ситуацию.
В общем остается ловить запрос от которого mysql впадает в транс.
Спасибо, очень приятно было пообщаться :)