форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"MySQL + SMP"
Сообщение от evg (??) 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 (??) 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 (??) on 16-Фев-05, 05:54  (MSK)
	up
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "MySQL + SMP"
	Сообщение от Асен Тотин on 17-Фев-05, 00:43  (MSK)
	Привет, идеология вкратце такова: MySQL выставляет обработку одного запроса (query) только одному процессору. Если у вас сами запросы проходят тяжело и следуют один за другим, то увеличение количеста процессоров вам ничем не поможет. То же самое делает и Apache, но поскольку он обрабатывает много запросов паралельно, то успевает разбросать их по отдельным процессорам. Как минимум, посмотрите статистику вашего SQL сервиса (в mysql консоли выставляем "\s" и списываем последнюю строчку). WWell,
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "MySQL + SMP"
	Сообщение от evg (??) 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"
	Сообщение от Асен Тотин 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 (??) 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"
	Сообщение от Асен Тотин 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 (??) on 18-Фев-05, 04:13  (MSK)
	Привет >А к вмин еще и индексы добавь... вообще, "du -sh" в директории, >где хранятся все базы (у меня - /usr/local/var) дает хорошее представление >обо всем произходящем. Но при таком количестве данных объем памяти тоже Не, я имел ввиду, что все таблицы innodb хранятся в файле заранее зарезервированного размера (tablespace). Нечто вроде собственной файловой системе. Так вот непонятно как там смотреть сколько под какие таблицы занято. >влияет на возможности сервера - ведь SQL engine старается держатя как >можно больше из них в памяти... 2G. Правда занято почти все. >Кажется, что вы выжали более-менее то, что можно было выжать в смысле >performance... Дальше идут только хитрости типа тьюнинга ядра и самого MySQL, >но недумаю, что это в состоянии резко улучшить ситуацию. В общем остается ловить запрос от которого mysql впадает в транс. Спасибо, очень приятно было пообщаться :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

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

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