Форум пользователей MySQL

Посещаемость - 100 тыс в день.

Уникальных посетителей ?

В общем ваш вопрос, как вопрос "Как быть здоровым ?" :-)
Способов как улучшить здоровье очень много, особо если знаешь что болит :-)

* Если у вас страницы не особо динамичны, то я бы начинал не с базы, а сначала попытался бы усилить кеш, во всех возможных местах.

* Поищите узкие места.
Начните с того же mysql_slow_log-a, посмотрите что больше всего напрягает базу.

Периодически mysql начинает тормозить, копится очередь.

А что происходит в этот момент ? Может заблокированные таблицы MyISAM ?

Проверьте что происходит с памятью.

Отредактированно evgeny (13.10.2011 22:07:42)

1. 100 тыс. это те что доходят до php, уникальные они или нет php и mysql по барабану . повторяющихся http запросов не более 15%. Каждая php страница генерит от 10 запросов к базе, но см. п.2.
2. Оптимизация была, есть и будет идти параллельно. Даже с оптимизацией с условиях роста столкнемся с проблемами. Сейчас пытаемся внедрять memcache. Вопрос не в этом.
3. Много сложных join, особенно в админке. Многие клиенты постоянно сидят в админке (рабочее место оператора).
3. Блокировки бывают не всегда, эту очевидность легко определить. Именно растет очередь, об этом я спрашивал и приводил примеры тут: http://sqlinfo.ru/forum/viewtopic.php?id=4750  но ответа там не получил. Упирается в диск, судя по всему. iostat показывает в моменты затыков wait 10, но, думаю это не очень много.
4. Если скажете как следить за памятью во FreeBSD буду благодарен. (Учитывая, что в современных системах память виртуальная и top совсем не показатель в этом плане).
5. InnoDB для прайсов, потому что они по паре гиг, обновление одного прайса может идти полчаса. Что будет с MyISAM в эти полчаса, думаю, сами понимаете. Прайсы обновляются частями - апдейтами. Создавать новую временную таблицу с прайсом, строить для нее индексы и потом переименовать займет в разы больше времени (и, следовательно ресурсов системы).

Возвращаясь к нашим баранам. Какие можете посоветовать направления увеличения вычислительной мощности кроме апгрейда железа одного сервера?
Я вижу простой способ: репликация мастер-мастер, селекты через рандом в php идут к разным сервакам, либо к доступному (если один лежит)
И сложный, но интересный и "модный" - создать свое облако из нескольких серваков и при необходимости просто добавлять в него новый сервак. Но информации по созданию своих облачных систем очень мало, и непонятно, опять же, как поведет себя mysql в этой среде.
Кластер, по своим ограничениям прироста производительности нам не даст, судя по всему, скорее наоборот.

В ситуации мастер-слейв если мастер упадет, то слейв обновления ему уже не пришлет (как я понимаю) и мастер не узнает, что в его отсутствие было что-то изменено.

PS: ОЗУ 24Гб, свап еле -еле вырастает до гига , но в моменты затыков он не увеличивается.

Отредактированно vova-c (15.10.2011 18:40:58)

В ситуации мастер-слейв если мастер упадет, то слейв обновления ему уже не пришлет (как я понимаю) и мастер не узнает, что в его отсутствие было что-то изменено.

Ну это не связано с мастер-мастер. Это связанно с механизмом который в случае падения, будет весь трафик перенаправлять на рабочий DB. То есть также с мастер-слейв, в случае падения мастера, слейв просто превращается в мастер.

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