Оптимизация mysql - есть мысли?

Покупка Quad-QuadCore-Opteron с 64 гигами памяти?

Приоритеты к процессам. Транзакционные базы данных. Правильное индексирование и кеширование. Оптимизация запросов к БД.

Кейворды.

И да, зачем так много соединений?

>... [много слов]

Это всё не спасает, когда в mysql запускается optimize table. Оно лочит таблицы насмерть.

>И да, зачем так много соединений?

Ну, если на форуме активный онлайн хотя бы 160, да все открывают разом по куче страниц, да надо запоминать всякую шнягу, типа когда последний раз в тему товарищ заглядывал - то не так уж много и выходит... :)

# евставить постгрес

не ?

>евставить постгрес

Не думаю, что постгре покажет себя лучше на примитивных запросах, типа, SELECT * FROM posts WHERE topic_id=12345 AND page=123.

Он выигрывает на сложной логике.

Мысли есть.

> Не думаю, что постгре покажет себя лучше на примитивных запросах, типа, SELECT * FROM posts WHERE topic_id=12345 AND page=123.

Гораздо лучше. Особенно если таких запросов 5-6 в секунду, и за ними следует незамедлительный апдейт. На таких запросах мускуль тихо задыхался.

>На таких запросах мускуль тихо задыхался.

Странно. Именно на таких (60% SELECT из больших таблиц, 40% UPDATE) у меня тянул на пике загрузки по 60-70 млн. запросов в сутки. В среднем по 800 запросов в секунду, а сколько там в пике - х.з., раза в два больше, наверное :) Когда до средних 200 запросов в секунду снизил, то машина в idle простаивать стала. Сейчас, вон, 114 запросов в секунду в среднем за последние трое суток (как раз упомянутое уменьшение коннекшнов) - так idle теперь чуть ли не до 2/3 всего времени :) - http://admin.airbase.ru/munin/airbase/airbase/cpu-day.png

Всё это на двух древних Xeon-1800.

А ты - про 5-6 запросов в секунду :)

>SELECT *

Ничуть не удивляюсь, что всё тормозит. Может ещё и таблицы не проиндексированы для всех используемых запросов?

А у вас сервер на FreeBSD или Linux? А то никак не могу под VDS FreeBSD прикрутить статистику по cpu и по памяти (всякая фигня получается).

Лучше бы какую книжку попросили про оптимизацию MySQL. Типа о секретах и трюках, для прожженых профессионалах, но не пересевших на постгрис. Неужели никто до вас этого не делал?

Да, тупой вопрос. А для получения статистики MySQL годиться любой логин:пароль? Я к тому выводиться обобщенная инфа или только подключенного юзера?

И почему запилили доступ к остальной статистике?!

> Есть какие-то умные мысли? Пока в голову приходит только на время оптимизации тупо обрубать доступ юзерам, типа, «извините, зайдите через 10 минут».

* a что, OPTIMIZE TABLE действительно так сильно помогает?

* может делать OPTIMIZE TABLE на другой машине? потом закачивать файлы оптимизированных таблиц на боевой сервер, подменять ими основные, и, заглянув в бинлог, применять последние изменения?

>>... [много слов]

>>Это всё не спасает, когда в mysql запускается optimize table. Оно лочит таблицы насмерть.

Точно - надо оптимизирвать одну копию таблицы, а раздачу делать из другой.

>>И да, зачем так много соединений?

> Ну, если на форуме активный онлайн хотя бы 160, да все открывают разом по куче страниц, да надо запоминать всякую шнягу, типа когда последний раз в тему товарищ заглядывал - то не так уж много и выходит... :)

А persistent connections? или у апача действительно 150 слейвов пашут?

почитай про организацию работы с бд в Skype :)

> # евставить постгрес

Там же тоже есть VACUUM, ручной или автоматический. Не будет ли это смена шила на мыло?

>>Это всё не спасает, когда в mysql запускается optimize table. Оно лочит таблицы насмерть.

А мама не говорила, что MyISAM нельзя использовать на продакшене?

> А persistent connections? или у апача действительно 150 слейвов пашут?

Если большая нагрузка — то да. Все 150. Если сервер некрупный, то такая веселуха начинается... ;-)

>А у вас сервер на FreeBSD или Linux?

Linux.

>И почему запилили доступ к остальной статистике?!

У меня там вся статистика открыта: http://admin.airbase.ru/munin/airbase/airbase/index.html

> Там же тоже есть VACUUM, ручной или автоматический. Не будет ли это смена шила на мыло?

AFAIK в нем все шли курить во время VACUUM только в шестой версии (насчет седьмой не помню). В текущей никто и не заметит, что он пылесосится.

>a что, OPTIMIZE TABLE действительно так сильно помогает?

Ну, ежедневная не так сильно, а вот еженедельная даёт уже заметную прибавку.

Естественно, речь идёт о больших часто модифицируемых таблицах.

>может делать OPTIMIZE TABLE на другой машине? потом закачивать файлы оптимизированных таблиц на боевой сервер

По времени только хуже будет. И в любом случае во время оптимизации на второй машине первую придётся блокировать. Бинлог тут особо не поможет, слишком много всяких тонкостей.

>А persistent connections?

Только хуже :) Оно держит коннект даже тогда, когда его можно уже отпустить. Вопрос нагрузки по времени установления не стоит, а вот удерживаемые активные коннекты жрут лишнюю память.

>или у апача действительно 150 слейвов пашут?

Апач у меня не сильно загружен. До 20-50 процессов. Основная нагрузка - Лайти. До 400+ запросов в секунду. По процессам рассчитать сложнее. 12 воркеров висит, каждый ещё внутри себя параллельные ветки держит.

>Гораздо лучше. Особенно если таких запросов 5-6 в секунду, и за ними следует незамедлительный апдейт. На таких запросах мускуль тихо задыхался

вы из какого прошлого к нам пришли? я чет такие цифры давно не видел, все больше тыщами измеряется.

Ололо. Похапешное лолбыдло не слышало о connection pool'ах и о кеширующих ORM? Хотя куда там. Кеширование запросов по типу memcached - ужасающий, нелепый костыль. И эти люди смеют наезжать на Java.

>> А persistent connections? или у апача действительно 150 слейвов пашут?

> Если большая нагрузка — то да. Все 150. Если сервер некрупный, то такая веселуха начинается... ;-)

и все 150 держат открытые соединения к базе? Вы что в базе фильмы храните и gprs-никам раздаете?

Не понимаю что на веб-загрузке на одном сервере с максимум четырьмя ядрами можно делать в 150 соединений к базе.

[root@xx ~]# netstat -nap|grep 3306|wc -l
1682

[root@xx ~]# ps ax|grep htt|wc -l
1022


Apache: 261 requests/sec

и все живое :)

> А мама не говорила, что MyISAM нельзя использовать на продакшене?

с InnoDB типа таблицы не лочатся, да?

use berkeley db

>И эти люди смеют наезжать на Java.

«С кем ты сейчас разговаривал?» (c)

> с InnoDB типа таблицы не лочатся, да?

Там при вставках-апдейтах блокировки все же на уровне записей, а не таблиц. Разницу чуйствуешь?

при оптимизации таблицы тоже?

Поставить второй mysql. На него реплицировать основной. Раз в сутки дублёра оптимизировать. На период подмены оптимизированных таблиц передавать управление на дублёра. Как-то так. Можно это дело делать на одной и той же машине впринципе.