Оптимизация MySQL

сервер можешь в подписи посмотреть.
а если есть желание - стукнись в аську, потому как у меня есть желание посмотреть что у тебя с мусклем

webboxxx писал:

ты может быть сам хорошо разбираешься в администрировании. а для меня все что выходит за рамки php и mysql - темный лес. а к платному админу по пустякам обращаться жаба душит.

А бесплатных админов, так - же как и бесплатного сыра - не бывает

webboxxx писал:

DELAYED не катит, в мане написано: DELAYED is ignored with INSERT ... SELECT

ты не понял. Тебе не этот запрос надо с delayed переписывать а как раз таки все остальные - тогда они будут закидываться в кэш а не ждать пока твой длинный селект завершиться и подвисать ничего не будет.

А вот совет про LOW_PRIORITY - имхо из вредных, я б даже сказал - вредительских Это ж надо - операцию которая итак всем мешает еще и затягивать по максимуму

shahfil: иди почитай про LOW_PRIORITY , что она делает и как, прежде чем чушь пороть.

Stek писал:

shahfil: иди почитай про LOW_PRIORITY , что она делает и как, прежде чем чушь пороть

Я то читал как раз, вот это например:

Код:

Note that `LOW_PRIORITY' should normally not be used with `MyISAM' tables as this disables concurrent inserts.

как раз из раздела про insert delayed между прочим.

Нахуй майизам таблицы в таком скрипте? Хочешь проблем себе на голову от бездеия получить...

яхуею дорогая редакция...

Не знаю я че вы в этом InnoDB нашли. Я вот тоже думал InnoDB это кул - типа все так писали. Пока не вышел на промышленный уровень.

Сейчас имеется база в 25 гигабайт. Стоит на сказевых рейдах и многих гигах оперативы.

Мы как то имели проблемы с блокировками MyISAM, даже когда база была не такая большая как сейчас. Пытались перевести ее на InnoDB. Так крутили и сяк крутили. Но как ни крути, на таких объемах и 1.5к тяжелых QPS, треды мускуля начинали безо всякой причины просто висеть. Мониторю базу - блокировок нет, все чисто. А случайные треды просто висят и теряются данные.

Переключаю таблицы обратно на MyISAM - полет нормальный. Мускуль был 5.0.х последний.

Впечатление такое, что вроде в ходе бета тестов все заебись. Шустро-быстро-красиво. Но только даешь реальную промышленную нагрузку - чпок, здравствуйте.

В общем хз че это было, с тех пор юзаю MyISAM, под его особенности проектируется база просто и нет проблем.

Последний раз редактировалось: Pentarh (20/01/09 в 14:14), всего редактировалось 1 раз

Поддержу Pentarh'а в его высказывании по поводу MySQL, по моим тестам на примерно такого же объема базах с массовыми инсертами InnoDB вообще не конкурент MyISAM'у.

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

Поясню почему спрашиваю: Учитывая ранее написанное замечание топикстартера о "в первой таблице есть уникальный индекс, ради которого соб-сно и нужно хранить весь объем" возникает вопрос - а нужно ли переливать все данные если реально необходим один индекс? К тому же неизвестно, может остальные поля в переливаемых данных - блобы с картинками Вообщем - возможно ли решение с введением третей таблицы, которая будет содержать данные, не относящиеся напрямую к самому нужному индексу - это уменьшит объем обрабатываемых данных.

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

Ну и еще вопрос - каков тип данных в самом индексе. Мне тут в одном проекте смена типа индекса с char на int помогла увеличить производительность (как раз на базах в несколько миллионов записей) в разы.

to pentarh (only!): скорее всего на твоём типе нагрузки, железе и уровне понимания механизма блокировок МайИзам действительно лучше чем ИнноДб. Двиг МайИзам действительно быстрее и устойчивее чем ИнноДб, но это только при грамотной организации запросов и структуре БД. В противном случае возникают проблемы как описал ТС, а именно - табличные блокировки во время изменяющих запросов.

Грамотным решением будет изменение алгоритма работы софта, с целью оптимизации операций чтения / записи в базу. Но для этого надо проделать некоторую работу.. и надо знать то что я написал выше. Кроме того возможно потребуется тюнинг мускуля и сервера, что тоже не простая задача и требует работы специалиста.

Более простым решением для человека который во всём этом не разбирается и имеет ОГРАНИЧЕННУЮ нагрузку на сервер является применение типа таблица ИнноДБ. В этом случае он на корню решит проблему блокировок во время изменяющих запросов, так как данный тип БД имеет транзакционную модель, и операции записи не мешают операциям чтения (в случае если не идёт чтение изменяющейся строки).

Да... к слову, при такой нагрузке тюнить сервак надо под любой двиг, но почему - то очень часто читаю о тюнинге именно под МайИзам. Что касается рабочих нагрузок - я не пру против течения, и стараюсь алгоритмически снять нагрузки... использую большие кеши, отложенную запись стопками, чередую циклы записи и чтения... это всё пока - что позволяет держать нагрузку на простенький сервак на уровне 1-10% при 400k - 1000k в сутки запросов.

Почитайте вот тут: http://www.insight-it.ru/tag/mysql/ там инфа о архитектурах различных крупных проектов. Если обобщить, то получается вот что:

Цитата:

Если Вам нужны транзакции — используйте InnoDB, если нет — MyISAM.

1) Если сервак под унихом, то перед стартом запроса можно попробовать понизить приоритет процесса MySQL сервера используя комманду
nice

2) 100% загрузка проца это одно,а провис сервака (точнее других процессов) это другое.

3) На безусловный SELECT индексы не очень повлияют, а вот на производительность INSERTa индексы таблицы-получателя влияют скорее отрицательно.

webboxxx писал:

кстати, подумываю, уж не сменить ли сервак этот.. старый он уже, знаю что переплачиваю, потому как устарело железо уже. Intel(R) Pentium(R) 4 CPU 2.80GHz, памяти 1гиг, трафа терабайт в месяц, фул-менеджед, 24/7 саппорт. $235. что сейчас за эти деньги я могу арендовать?

у нас можно с 2терабайтами трафа взять Core2Quad 4-ядерный с 4гигами памяти и SATA-винтом на 500гиг за 199$
или тоже самое но с 2 процессорами XEON по 2 ядра каждый за 270$

Спасибо, повесили все, от стар до млад. Но STAR вообщем все отписавшиеся. В мульонный раз убеждаюсь, что на форумах совета просить, так насоветуют хоть уй медом намазать и в улий сунуть, а другие подскажут у кого улий круче и дешевле, только, ..., проблемы это не решит - умирает, господа, не адалт, а комьюнити и "мозг адалтщика"... я еще удивляюсь, как тут Сергёйка еще сигнатурой не засветился.

ТС, если не нужно "приседания" серва на Х минут, то пересматривай "схему работы", ибо имхо, толь это из советов выше, можно считать полезным.

Жуй ;)

Heavy писал:

Спасибо, повесили все, от стар до млад. Но STAR вообщем все отписавшиеся. В мульонный раз убеждаюсь, что на форумах совета просить, так насоветуют хоть уй медом намазать и в улий сунуть, а другие подскажут у кого улий круче и дешевле, только, ..., проблемы это не решит - умирает, господа, не адалт, а комьюнити и "мозг адалтщика"... я еще удивляюсь, как тут Сергёйка еще сигнатурой не засветился. ТС, если не нужно "приседания" серва на Х минут, то пересматривай "схему работы", ибо имхо, толь это из советов выше, можно считать полезным.

Пиздеть мастак смотрю? А по делу?
Sirgey: Найс мускулю это реально жесть )

Много буковок увидел, а вникнуть не удосужился? - Лапти не правильно одеваете, в этом и беда.
ТС делает вставку по выборке, как ты думаешь, что будет с таблицей(ами), из которой(ых) идет выборка? Она будет залочена, дабы в процессе первичного запроса ничего не поменялось и тут мускуль пиздецки прав, и нечего на него гнать. Т.ч. готовьте любимых кошечек правильно

Хеви, мы распинаемся чтобы объяснить ТС как работает мускуль, в чём разница в типах таблиц и какие блокировки и как действуют на них в зависимости от типа. А ты в этом НИХУЯ не понимаешь. Если внимательно прочитать то что запосчено выше - то ты поймёшь, что мы как раз и объясняем как можно надеть лапти именно таким образом, и чтоб не слетали.

Проходи мимо...