MySQL на SSD

Откуда у вас такие проблемы с такой низкой нагрузкой? Добавить ещё ОЗУ (опционально) и сделать кэш большим, чем размер БД.

По теме: Мониторь бэкапы.

возможны только две витуации, при которых может на такой низкой загрузке и таком кол-ве памяти тормозить мускуль - либо нагрузка в основном update, с разных потоков конкурентно за одни и те же блоки, либо на сервере есть что-то еще. ТС, что у тебя? в любом случае, какой характер нагрузки мускуля?

Какие есть :) в пика в двое выше. Озу в этот сервер больше не лезет :(

Кеш больше, написал в топике.

Тут нужно искать проблемы в коде. Причём, скорее всего, они выплывут даже с ssd, когда нагрузка ещё увеличится
. Можешь данные с мунина по запросам показать?

На сервере только мускул. ~10% update, 5% insert/delete

Вот данные мониторинга (~2Mb) http://www.sendspace.com/file/9tq04h

На проекте средний онлайн ~1.5к, постоянный клик, соответственно запросы к базе.

То что нужно оптимизировать код, это понятно :) Но это уже другой вопрос, сейчас нужно жить с тем что есть, и как-то улучшить отзывчивость мускула

Небольшой оффтопик - используйте что-то вроде memcached, чтобы постоянно не дёргать БД. Но опять же это изменение архитиктуры и куча работы. Возможно, у вас есть запросы, где используются функции или join. Это тоже нужно убирать.

У SSD есть такое достоинство - после того, как ячейка умирает, она просто становится ro, т.е. данные с неё прочитать можно.

Думается, тут нужно мониторить стандартно. Всякие Reallocated_Sector_Ct и Seek_Error_Rate. Правда, хз как тут с SSD.

На всякий случай, покажи my.cnf

используйте что-то вроде memcached, чтобы постоянно не дёргать БД

спасибо, кэп

где используются функции или join. Это тоже нужно убирать.

какое отношение это имеет к загрузке по IO?

Используем Redis. Иначе было бы как минимум 5*на онлайн запросов/сек.

my.cnf - http://pastebin.com/puHm61bx

Забыл добавить, если кто будет смотреть графики мунин. на SSD переехали вчера в обед /dev/sdc

smartd и оптимизировать запросы, даже, если это «невозможно». При такой нагрузке - проблема не в диске, а в конфигурации mysql, либо, что более вероятно, «кривые» запросы.

Ещё возможны проблемы с диском или его контроллером.

Оптимизировать возможно, конечно, но это время, которого всегда не хватает... Конфиг выложил. крутил уже по всякому.. Запросы может и кривые, но мне кодерам нужно как-то это аргументировать более конкретно чем «это не нормальный лоад».

Посмотри slow queries - будешь видеть, Какие запросы тормозят. Если при выполнении запроса есть обращение к диску, то он там точно появится.

log-slow-queries=/var/log/mysql-slow-queries.log
long_query_time=1

Имеем базу ~6-7Gb

16GB RAM

~350 queries/sec

все тормозило на IO wait

Эти 4 факта дают полное право утверждать, что у вас просто-напросто ушибленная на голову структура базы. Также libastral.so подсказывает, что такая конфигурация (когда все данные влезают в память) в принципе не способна тормозить на IO при выборках, что ведет нас к заключению, что вокруг этих 6-7 гигабайт данных (это ведь размер данных или du на директорию?) понавешадо черезчур дохрена индексов, что вкупе с частыми INSERT/UPDATE/DELETE способно породить некислый IO. Но это опять-таки лечится иннодбшными настройками, которые заставляют мускуль писать на диск не после каждой операции, а накапливать изменения в течение некоторого времени.

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

Что нужно мониторить чтобы не проспать смерть SSD ?

Настраивайся на то, что ее нужно не «не проспать», а мгновенно на нее среагировать. Держи актуальную реплику наготове, читай slow log и учись использовать explain, тогда SSD при такой откровенно смехотворной нагрузке не понабодятся.

А ты уверен, что SSD тебе даст прирост производительности? Например, Plextor M2S PX-128M2S SATA III, он рассчитан на 6 Гб/с, следовательно подключать его нужно напрямую к контроллеру. Экспандеры(если такие есть в корпусе) обычно 3 Гб/с. Да и сам контроллер должен быть 6 Гб/с. Пробовали кингстоновские диски на HP DL365G1/5, прирост был 5% относительно SAS, правда без TRIM.

У меня мониторилка заббикса долбит мускуль с иннодб на 200 запросов в секунду, причем где-то 80% UPDATE, 15% INSERT. Диски - 8 древних SAS 10K 36Gb в рейд10. Никаких намёков на проседание IO даже близко нет. Так что что-то у тебя явно не так со структурой и\или запросами, если даже на селектах проседает...

По статистике меня смущает 300 тысяч Innodb Row Operations в секунду...

да причем тут гигабайты? человеку иопсов не хватает, а вы про гигабайты.

кстати, есть мнение что такое IO может быть изза чтения с диска. посмотри iotop. если есть много чтения, то его можно уменьшить отключив read ahead на винте с базой.

да причем тут гигабайты? человеку иопсов не хватает, а вы про гигабайты.

при том, что пропускная способность и есть iops * количество передеваемой информации, не?

не. iops это грубо говоря количество транзакций, а гигабайты они и в африке гигабайты, и с количеством транзакций слабо коррелируют.

Мне когда-то сильно помог перевод базы innodb на формат barracuda

http://dev.mysql.com/doc/innodb-plugin/1.0/en/glossary.html#glos_barracuda