MySQL в tmpfs

[@Azy]

Парни, да в случае с множеством инсертов разумеется нужно перейти на InnoDB. Почему не попробуете?

еще рекомендую глянуть в сторону memcacheDB

[@ghisguth]

Мы использовали MyISAM в прошлых проектах, но там была стандартная схема хранения пользовательских данных в базе и при каждом запросе участвовала база данных. Это первый проект в котором пользовательские данные хранятся в памяти и сохраняются при логауте или по интервалу.

Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.

Про memcacheDB слышали, если мне не изменяет память — это интерфейс поверх BDB. А так как tyrant — показал себя намного лучше, чем bdb — то мы склонны использовать все таки его. Но в tyrant есть и свои минусы, поэтому мы не спешим с переходом.

[@Azy]

Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.

Разумеется там есть нюансы ) Тюнинг там немного отличается от тюнинга MyISAM.

Я бы еще попробовал сделать связку Master-Master. Бин логи на отдельном диске вы правильно сделали — это очень критичная штука.

MemcacheDB — это как вы и написали интерфейс поверх BDB. А вот бенчмарки из MemcacheDB: A Complete Guide

[@pgrishin]

вы сами использовали memcachedb?

[@Azy]

На production проектах нет, только в качестве пощупать на локальном стенде.
Если интересует вариант именно практического применения, то спросите у пользователя magnit — у него имеется более детальное представление о сабже.

[@Aa1111]

ИМХО, Вам стоит рассмотреть следующий вариант:
1. берем на продакшене таблы, которые чаще всего ЧИТАЮТСЯ оставляем MyISAM
2. таблы, которые равномерно читаются / изменяются и ОЧЕНЬ ЧАСТО — MEMORY, иначе InnoDB
3. таблы, которые чаще изменяются InnoDB

Потому, что
1. MyISAM — очень быстро вибирает, но при изменении таблы лочится ВСЯ табла.
2. InnoDB — чуть медленнее выбирает, но при изменении лочится строка(ки).
3. MEMORY — вся висит в ОЗУ, но оно не резиновое.

При таком подходе мы сняли нагрузку на кластер БД, переведя ЧАСТЬ таблиц на InnoDB и MEMORY на столько, что смогли отказаться от кластера :)
проект имеет 40..60к уников в час.

Надеюсь, что этот опыт будет Вам полезен.

[@MARDEN]

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

[@Aa1111]

Совершенно с Вами согласен. Просто у нас не все таблицы были связаны ключами, поэтому и можно было разделить.

[@amxm]

Убило что из бекапа нельзя восстановить базы innodb, только если SQL дама постоянно делать…

[@akzhan]

по-хорошему надо просто реплицировать.

[@achurkin]

Ага, конечно (=
Как репликация спасет от случайного DELETE или TRUNCATE?

[@akzhan]

недоговорил ) у меня настроена репликация со слейва через mysqlhostcopy/rdiffbackup.

[@pwlnw]

А от этого спасает репликация с задержкой.

[@mente]

Berkeley не выдает хорошую производительность на больших количествах запросов.

[@Aa1111]

А Вы не пробовали использовать двиг MEMORY?
В нем таблы и так висят в ОЗУ :)

[@ghisguth]

А про MEMORY мы и забыли;) Как по мне администрирование базы на tmpfs проще, чем использование MEMORY — потому как используются все те же скрипты и подходы, только мы работаем с очень быстрым диском.
Ещё тут вопрос как бекапить таблицы? Мы используем бекап файловой системы, которая находится в памяти (mysqldump в разы медленнее), а вот как быть с MEMORY — не знаю.

[@pgrishin]

как вы, интересно, бекапите файлы? просто копированием?

[@ghisguth]

Да, в статье есть ссылка на mylvmbackup, на базе которого мы и бекапим базу. Раньше так же бекапили, когда slave был на lvm диске.

[@akzhan]

mysqlhotcopy?

[@ekungurov]

Насколько я знаю, у него множество ограничений.

[@MARDEN]

Да, в доках всё описано.

[@achurkin]

Как мемкеш поможет смасштабировать update-ы?

[@achurkin]

Чуть выше в посте есть график. Так вот там красненьким отмечено количество UPDATE-ов. И их куда больше чем SELECT-ов.

[@achurkin]

Может быть еще куча-куча если и вдруг. Давайте отделим влияние других факторов. Пост про высокий I/O и масштабирование при данном профиле нагрузок. И при данном профиле нагрузок толку от memcache будет 0.

[@ghisguth]

У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.

Хотя memcache тоже используется в некоторых местах, но работать с данными напрямую в памяти в сотни раз быстрее.

[@ghisguth]

Проект — игра. Экономический симулятор. При входе в игру загружаются данные и начинается симуляцмя в С++. Периодически последний этап симуляции на всех объектах пользователя сохраняется в базу.
Мы меняли нагрузку увеличивая интервал сохранения, но это чревато тем что упадет демон и пользователь откатится на большое время назад.
Сами таблицы и индексы достаточно простые (грубо говоря несколько таблиц objects в которых есть user_id индекс, а сохранение производится по primary key). Просто данные активно меняются. И да, записываются только те данные, что изменились.

[@achurkin]

Навскидку вам можно посоветовать такие решения:
1. Partitioning tables + InnoDB + разделы на разных дисках. Появилось в MySQL 5.1.
2. Если у вас все настолько просто и нет необходимости джойнить таблицы, а MySQL в основном используется как key-value storage, то вам будет очень легко горизонтально зашардить таблички.

Ну уж точно надо отказываться от tmpfsm, в первую очередь, а во вторую от MyISAM.

[@ghisguth]

InnoDB будем пробовать в ближайшем времени.
Код для горизонтального масштабирования написан и протестирован. Но мы планировали его использовать для кластеризации на несколько серверов. Попробуем горизонтально зашардить в связке с InnoDB.
Спасибо за совет.

[@achurkin]

Простите, но у вас не единственная проблема. У вас очень высока вероятность потерять данные. Данные на реплике не всегда будут соответствовать данным на мастере из-за задержек репликации.
А InnoDB, в принципе, может сократить IO. Зависит от многих факторов.

[@lehha]

БД 10 гб, slave на соседней полке — в сутки порядка 5GB insert/update — реплика очень редко отстает на 1 секунду.

[@torsten]

и тут вдруг прорывает батарея и заливает все кипятком:))

[@achurkin]

Или, например, падает сетевуха на реплике.

[@lehha]

Ну это если tmpfs, а я говорю про обычный sata-диск на реплике — она всегда актуальна. Тьфу-тьфу))

[@mgyk]

InnoDB просто нужно вменяемо готовить. Если вам не критична потеря данных за последние пару секунд innodb_flush_log_at_trx_commit=2 даст сбрасывание транзакций на диск раз в две секунды, что очень сильно прибаляет скорости.

[@kashey]

Искал когда же люди напишут это.
Еще очень сильно могут помочь опции commit=5-10-15 и другие relatime в настройках самого маунта диска.

[@BreathLess]

Вы молодцы, но в вашей системе не хватает пакета aspell-ru.

[@karellen]

Just pipe it to /dev/null!
www.xtranormal.com/watch/6995033/

[@Masterkey]

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

ЗЫ походу там два дурака разговаривают %)

[@achurkin]

Количество данных, которые можно потерять на монго в разы меньше тех, которые можно потерять при той архитектуре, что нам предложил автор поста (=

[@Masterkey]

я про ролик рассуждал

[@Masterkey]

мда, а вы тоже самое не пытались делать с помощью встроенных утилит мускула? он ведь и сам может поместить базы в оперативу и писать апдейты на диск с отложением, а?

ну и так на будущее
www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/
www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

PS удачных велосипедов

[@Psih]

Да, mysqlperformanceblog вообще must read любому, кто имеет дело с MySQL.

[@ghisguth]

Никто и не говорил, что мы останемся на этом решении и не будем пробовать. В частности для обмена опытом и создавался этот топик. Хотя нулевой la нам очень нравится;)
За ссылки спасибо.

[@Psih]

Как уже многие писали — в вашем случае панацея — это InnoDB и его правильный тюнинг.
Вам нужно взять Percona Server (в нём можно настроить кол-во threads для чтения/записи данных, это уже само по себе позволяет распределить нагрузку), настроить log buffer на что-нить типа 20-50MB — получите запись крупными блоками на диск, что гораздо быстрее и эффективнее, чем рандомная запись, особенно на SSD. InnoDB buffer pool выставляете побольше — тогда в памяти постоянно будет висет большое кол-во данных и индексы — в этом случае InnoDB легко взлетает — выжимали до 3000 запросов из 2х2 Xeon'a ещё модели 2006 года, на нынешних можно выжать куда больше.

В общем, ИМХО, статья у вас получилась по незнанию «Как делать не надо». Один раз у вас что-то полетит и можно очень и очень сильно вляпаться с таким подходом. UPS иногда, знаете ли, тоже ломаются, RAID-5 умирают и происходят прочие, не менее странные вещи. Законы Мерфи, итить их за ногу.

[@ghisguth]

Спасибо за подробную информацию. Вы мы будем пробовать InnoDB. А статья может и «Как делать не надо», но в качестве быстрого решения — тоже вариант. В частности для обсуждения этого вопроса и создавалась эта статья.

[@AGvin]

Не подскажете где можно что-то про Percona Server прочитать. В стиле «Тюнинг Percona Server»...?

[@Psih]

Их блог: mysqlperformanceblog.com/
А так же их книга: www.amazon.com/gp/product/0596101716?ie=UTF8&tag=perinc-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596101716

[@dimoclus]

Перечитал пост дважды, но так и не нашел описания того, что будет, когда вдруг отключится электричество или понадобится ребут по техническим причинам. Получится закат солнца вручную (описанный паттерн «падение двух слейвов») или где-то в дебрях /etc/init.d лежат скрипты, которые заберут нужный снапшот базы из нужного места и развернут ее?

И вообще, оптимизация дисковых операций выглядит так: 1. убеждаемся, что для «горячих» select'ов у нас есть необходимые индексы и при этом их не так много, чтобы они убивали операции insert/update; 2. задействуем головной мозг и избавляемся от лишних запросов (можно использовать memcached). И только после этого, если ничего не помогло, имеет смысл копать «вглубь», перемещать данные в tmpfs и так далее, и тому подобное.

[@Palatinus]

конечно все скрипты для поднятия со слейва написаны и подключены… скорость восстановления если машина рухнула состоит из времени поднятия машины+копирования бекапа+ разархивирования его + поднятие базы в среднем занимает около 3-5 минут, ну так если сервер рухнул в любом случае демоны не могут до стучаться до базы пока сервер лежит… теряется время в отличии от стандартного подьема сервера отличается только на копировании и развертывании бекапа…
1. 2. проблема не в селектах (У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.) если это выключить и оставить на базе, то селектов будет около 5000 к 500 апдейтов и 100 инсертов. Когда такое было не помогал ни мемкеш не что либо… поэтому и был написан демон робота которого как мемкеш только на С++ поэтому в разы быстрее… и в итоге уперлись в апдейты при работе с дисками…

[@achurkin]

И насчет MySQL в общем — почитайте MySQL Perfomance Book. Относительно недавно вышел перевод 2-го издания на русский язык.

[@ColorPrint]

www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/0596101716/ref=sr_1_1?s=books&ie=UTF8&qid=1284498524&sr=1-1
Это она?

[@achurkin]

Ага. А есть перевод ее — www.books.ru/shop/books/734220

[@bdmalex]

В общем единственная потенциальная проблема — это рост базы. Но сейчас память в серваках достаточно дешевая и увеличить её не составит проблем (на части машин у нас 16Gb, на части 8Gb, но, насколько мне известно, можно поставить в потолке 128Gb)
Купите сервачок в 2U всё само будет только в оперативной памяти…

[@Masterkey]

много раз облизнулся, но слюни всеравно текут…

[@bdmalex]

Мне тоже машинка очень нравится, единственное что стоит приличных денег даже в минимальной платформе(подумываю не взять ли её в лизинг)
и конечно, если её ставить на коло в РФ — то доплачивать придётся за мощность(а это обычно приличные деньги). В нашем латвийском ДЦ за коло такой тачанки возьмут всего 1450р(или со скидкой можно — 1233р)…

[@Psih]

128 уже давно в обычный сервак лезет, щас 192, а то вроде уже и 256 есть :) Модули по 8GB и 16GB анонс вроде проскакивал :)

[@bdmalex]

В предлоеденном мною серваке 512Г в 2U при желании можно разместить…

[@fearan]

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

you made my day.

[@ghisguth]

Памяти много и она не используется. Большенство параметров в MyISAM выкручены до максимума. IOwait не из-за свопа, а изза записи на диск. А настроек позволяющих снизить нагрузку на диск в MyISAM нет, они есть только в InnoDB, на который и советовали перейти выше.

[@fearan]

Прочитал по диагонали.

MyISAM, 400 инсертов/апдейтов… OMG. Все еще хуже.

[@psyche]

Tmpfs вообще хорошо помогает, там где идет активная работа с диском. Я так с Imap-Cyrus баловался на допотопном железе.

[@patt]

Если запросы в основном на запись, то можно попробовать PostgereSQL

[@ilukyanov]

howfuckedismydatabase.com/mysql/

[@non7top]

приставки «з» не бывает.

[@Kalashmatik]

Кстати еще tmpdir = /dev/shm в конфиге, мелочь, а приятно :)

[@Palatinus]

скорость восстановления если машина рухнула состоит из времени поднятия машины+копирования бекапа+ разархивирования его + поднятие базы в среднем занимает около 3-5 минут, ну так если сервер рухнул в любом случае демоны не могут до стучаться до базы пока сервер лежит… теряется время в отличии от стандартного подъема сервера отличается только на копировании и развертывании бекапа…
слейвы при подъеме мастера со слейвы поднять меньше минуты…
про mysqldump забыли уже давно… бекапим методом снапшотов LVM, а данном случае снапшотов памяти
опыт сейчас работает

[@ilukyanov]

у вас на 100 апдейтов одной записи идет одно ее чтение. Вывод — 99 из 100 апдейтов бесполезны и их можно выбросить.

зачем вам тут вообще база? складывайте сериализованные данные по пользователю на FS одним файлом. Придет пользователь снова — прочитаете. Или храните все его объекты в одном поле в бд в виде блоба или xml между сессиями.

[@Palatinus]

Чтений на много больше только их отдает демон С++ (У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.) если это выключить и оставить на базе, то селектов будет около 5000 к 500 апдейтов и 100 инсертов. Когда такое было не помогал ни мемкеш не что либо… поэтому и был написан демон робота которого как мемкеш только на С++ поэтому в разы быстрее… и в итоге уперлись в апдейты при работе с дисками…

[@ilukyanov]

Ну да, так это не противоречит моему утверждению. Из самой базы вы читаете редко, а значит постоянные ее апдейты просто мозолят диск, создавая ненужный overhead. Ошибки здесь две:

1) вам абсолютно не нужна здесь реляционная база для хранения стейта пользователя. без разницы, где все это хранить. на файловой системе, в key-value или еще где то.

2) если все же хочется мускуль. зачем вам в базе квантовать состояние игры пользователя до отдельных объектов? собирайте их в один большой массив, объект или что у вас там, сериализуйте его и пишите с той же частотой в базу. Апдейтов будет в N раз меньше, где N — количество объектов под одним пользователем.