The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"MySQL + SMP"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"MySQL + SMP"
Сообщение от evg emailИскать по авторуВ закладки(??) on 15-Фев-05, 11:13  (MSK)
Здравствуйте
Имеется сервер с 4мя процессорами. На нем линукс (ядро 2.4.21-4.ELsmp), mysql (4.1.8) и апач с php.
Я не администрирую его (да и вообще работаю исключительно с fbsd), но к сожалению администратор болеет, поэтому пришлось мне им заняться. Начались проблемы с загрузкой. Типичная картина, когда mysqld-max грузит ОДИН процессор на 100%, а апач выстраивает очередь на остальных в ожидании обслуживания. Т.е. картина ясна - mysql не желает запускать треды на разных процессорах.
На сайте mysql нашел два замечания касающиеся работы на smp архитектуре и тредов в линуксе.
1. Если "много" (?) процессоров, то нужно сооружать из них кластер (ndbd). Делать этого совсем не хочется.
2. Для реализации тредов в линуксе нужна linuxthread. Однако, как я понимаю, без тредов mysql вообще бы не запустился. Значит библиотека имеется.
Чем же еще можно вылечить эту проблему?
  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "MySQL + SMP"
Сообщение от evg emailИскать по авторуВ закладки(??) on 15-Фев-05, 13:49  (MSK)
up
  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "MySQL + SMP"
Сообщение от evg Искать по авторуВ закладки(??) on 15-Фев-05, 18:37  (MSK)
up


  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "MySQL + SMP"
Сообщение от evg emailИскать по авторуВ закладки(??) on 16-Фев-05, 05:54  (MSK)
up


  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "MySQL + SMP"
Сообщение от Асен Тотин emailИскать по авторуВ закладки on 17-Фев-05, 00:43  (MSK)
Привет,

идеология вкратце такова: MySQL выставляет обработку одного запроса (query) только одному процессору. Если у вас сами запросы проходят тяжело и следуют один за другим, то увеличение количеста процессоров вам ничем не поможет.

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

Как минимум, посмотрите статистику вашего SQL сервиса (в mysql консоли выставляем "\s" и списываем последнюю строчку).

WWell,


  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "MySQL + SMP"
Сообщение от evg emailИскать по авторуВ закладки(??) on 17-Фев-05, 04:16  (MSK)
Выглядит очень логично.
К сожалению (или к счастью), пока что нагрузка не повышалась до критических пределов, поэтому оценку произвести не могу. Пока что так:
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".
Спасибо за разъяснения!
  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "MySQL + SMP"
Сообщение от Асен Тотин emailИскать по авторуВ закладки on 17-Фев-05, 12:08  (MSK)
Привет,

> Threads: 4  

Т.е. в случмае необходимости и возможности пользуем все 4 процессора...

> Slow queries: 0

Это хорошо, значит все базы у нас проиндексированы как  следует.

> Queries per second avg: 264.068

А вот это говорит, что у нас довольно-таки загруженный SQL сервер. Интересно было бы проследить объем баз данных (кол-во записей и количество данных в МВ) и их соотношение са наличной памятью.

WWell,

  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "MySQL + SMP"
Сообщение от evg emailИскать по авторуВ закладки(??) on 17-Фев-05, 13:12  (MSK)
Привет
>> 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 документов с индексацией по тэгам. Хотя "витрина" получается вроде как быстрой, поскольку состоит из сгенеренных статических фрагментов отображаемых по результатам поиска. Да и сами результаты поиска так же кэшируются.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "MySQL + SMP"
Сообщение от Асен Тотин emailИскать по авторуВ закладки on 17-Фев-05, 14:52  (MSK)
Привет,

>вообще все базы порядка 10G в дампе (по результатам переезда)

А к вмин еще и индексы добавь... вообще, "du -sh" в директории, где хранятся все базы (у меня - /usr/local/var) дает хорошее представление обо всем произходящем. Но при таком количестве данных объем памяти тоже влияет на возможности сервера - ведь SQL engine старается держатя как можно больше из них в памяти...

>Все таблицы поделены на критичные и некритичные в смысле транзакций
>некритичные (MyISAM) - 1.1G (здесь вся статистика и прочий мусор)

>критичные (InnoDB) - не могу оценить поскольку все в одном файле -
>как с ним работать не представляю. На все базы 6G
>Количество таблиц: 96
>Максимальное количество полей: 48
>Максимальное количество записей: 6030548 (статистика)

При шест миллионах записях - InnoDB действительно лучше.

Кажется, что вы выжали более-менее то, что можно было выжать в смысле performance... Дальше идут только хитрости типа тьюнинга ядра и самого MySQL, но недумаю, что это в состоянии резко улучшить ситуацию.


  Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "MySQL + SMP"
Сообщение от evg emailИскать по авторуВ закладки(??) on 18-Фев-05, 04:13  (MSK)
Привет

>А к вмин еще и индексы добавь... вообще, "du -sh" в директории,
>где хранятся все базы (у меня - /usr/local/var) дает хорошее представление
>обо всем произходящем. Но при таком количестве данных объем памяти тоже

Не, я имел ввиду, что все таблицы innodb хранятся в файле заранее зарезервированного размера (tablespace). Нечто вроде собственной файловой системе. Так вот непонятно как там смотреть сколько под какие таблицы занято.

>влияет на возможности сервера - ведь SQL engine старается держатя как
>можно больше из них в памяти...

2G. Правда занято почти все.

>Кажется, что вы выжали более-менее то, что можно было выжать в смысле
>performance... Дальше идут только хитрости типа тьюнинга ядра и самого MySQL,
>но недумаю, что это в состоянии резко улучшить ситуацию.


В общем остается ловить запрос от которого mysql впадает в транс.
Спасибо, очень приятно было пообщаться :)

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру