Перенос баз mysql в ОЗУ во имя производительности

Ну и какие ещё варианты увеличения производительности БД?

нужно для начала тюнить sql запросы.

можно ли перенести БД в ОЗУ?

И чего только люди не изобретают, лишь бы софт нормально не писать.

Какое решение будет наиболее оптимальным для продакшена? Увеличит ли это скорость записи в БД?

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

Не поможет, если ссд быстрый, субд правильно настроена и запросы оптимизированы. Попробуй таблицы типа MEMORY, но у них свои ограничения.

А так переходи на in-memory субд.

Там каждые 10 секунд с кучи сайтов собирается статистика, которая пишется в БД. Сейчас используется движок innodb.

Остальное пока не знаю.

Там каждые 10 секунд с кучи сайтов собирается статистика, которая пишется в БД.

Еще в конце 90-х на nt4+mssql6 скада сотни мгновенных данных нормально укладывала. Так что все-таки разбирайтесь с софтом (субд тоже) в первую очередь.

перенаправляй сразу в /dev/null

Does /dev/null support sharding?

Остальное пока не знаю

ну тогда оставь субд в покое.

перкону переходите. на платную версию.

Пока мне приятель предложил перевести нужные БД и таблицы на myisam вместо innodb. Я в этом деле нупЪ, просто у нас сервак за сутки 2 раза упал.

Ну храни ее в tmpfs. Только смотри, рискуешь потерять все разом.

innodb_buffer_pool_size=100500G. Короче, насколько памяти хватит (но учти, что кроме пула её жрут всякие кэши, которые создаются на каждое соединение - точную формулу рассчёта b_p_s ищи в гугле).

innodb_buffer_pool_instances=число ядер

innodb_file_format=Barracuda

innodb_file_per_table=1

Если per_table изначально не стояло, то после его включения придётся дропать базу и заливать дамп заново.

query_cache можно метров 128 выставить, если частые одинаковые селекты, и при этом нет извращенцев, пишущих комментарии к запросам прямо в них. Скорость записи увеличит, но не сильно. Если проблема именно в записи и при этом база нагружена чтением - юзай две или больше ноды (мастер под запись и слейв(ы) под чтение).

Ещё можно поставить мускуль посвежее - 5.6 перкону или 5.7 родной.

Майисам с его lock granularity = всей таблице, отсутствием транзакций и бредовейшей процедурой восстановления после сбоя - не нужен.

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

Если отправлять данные в /dev/null сразу у клиента, то это будет гораздо быстрее.

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

По теме, если write-only нагрузка или около того, то классические BTree не очень, как только база выходит за размер оперативы.

Если оперативы ещё много, тогда подкрутить innodb_log_file_size (больше двух файлов на 8гб не нужно крутить).

innodb_flush_log_at_trx_commit в 2, если диски по sysbench fileio тесте «How many fsync / sec FusionIO can handle» здесь можно посмотреть строчку запуска. Почему так? Сильно больше транзакций на запись, чем эта цифра не получится сделать.

Если за один заход много строчек заливается, тогда надо не от балды сразу 10 миллионов в одной транзакции лить а как-то меньше по 100-200k строчек максимум: «How to load large files safely into InnoDB with LOAD DATA INFILE»

Для mysql можно таблицы с большим количеством записи сконвертировать в TokuDB (по началу может быть медленнее чем innodb, но подкрутив ручки будет лучше).

MEMORY таблицы специфические, например varchar(255) будет храниться как char(255) (и жрать оперативы больше чем надо).

innodb_buffer_pool_size=100500G. Короче, насколько памяти хватит

У сервака вроде 64 гига ОЗУ.

Остальное попробую.

Увеличит ли это скорость записи в БД?

Зависит от того, является ли сейчас скорость записи bottleneck'ом. Если что, в линуксе есть кеш записи, в ОЗУ. http://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-diskio.html

По теме, если write-only нагрузка или около того,

В основном, UPDATE и INSERT.

Если база около 20гб и сильно расти не будет, тогда innodb_buffer_pool_size = 30G

Если база больше, тогда innodb_flush_method = O_DIRECT, innodb_buffer_pool_size = 40G или 50-58G (надо смотреть чтобы не было свопа).

Если в серваке несколько сокетов и база большая, тогда включать NUMA interleave

После любых модификаций буферпула надо смотреть не свопит ли (или перестало ли свопить).

sysctl vm.swappiness в 0 или 1 в зависимости от того какое ядро.

Если база больше 60GB, и все горячие таблички, надо попробовать поделить на несколько серверов или добавить памяти или заюзать току с zlib копрессией (или снаппи/lzo т.к. всё-таки ssd).

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

Ты небось дрочишь^W пишешь логи в базу?

Надо знать цифры, их есть много в mysqladmin ext -i1 -c30 вывод которого можно посмотреть в pt-mext (будет сколько попугаев каждого параметра в секунду на интервале 30 секунд).

и уже тогда можно сравнивать свои цифры с чужими: https://www.percona.com/blog/2014/05/23/improve-innodb-performance-write-boun...

или http://dimitrik.free.fr/blog/archives/2013/01/mysql-performance-innodb-heavy-...

надо погонять sysbench

Во время работы прогнал по скорости чтения и записи ssd:

Read 19.184Gb  Written 12.789Gb  Total transferred 31.973Gb  (109.13Mb/sec)
 6984.58 Requests/sec executed

По БД не гонял, правда.

БД суммарно меньше 20Гб. Насчёт будет ли расти - сложно сказать. На сервере много проектов хостится.

А вообще спасибо за совет, сейчас попробую.

Ты небось дрочишь^W пишешь логи в базу?

Ну как сказать. Собираются с нескольких десятков сайтов статистика по скриптам, и она уже пишется в БД. Так что отчасти да, логи в базу.

Там каждые 10 секунд с кучи сайтов собирается статистика, которая пишется в БД

И эти данные потом нужно хранить? Или как-то обработать и хранить только результат обработки?

Так что отчасти да, логи в базу.

Если это какой-нибудь timeseries для мониторинга, то графит/influxdb для этого предназначен гораздо лучше. Как правило, нет такой проблемы «как быстро писать много данных в mysql», поэтому советовать по факту нечего.

еревести нужные БД и таблицы на myisam вместо innodb. Я в этом деле нупЪ, просто у нас сервак за сутки 2 раза упал.

до до, расскажешь потом как там консистентность в myisam после падения 8)

И эти данные потом нужно хранить? Или как-то обработать и хранить только результат обработки?

Там сбор статистики от виджета. Куда нажимали, сколько раз, какие движения мышью были и всё в этом роде. Потом данные используются для вывода статистики.

Если это какой-нибудь timeseries для мониторинга,

Это больше похоже на что-то вроде Яндекс.Метрика.

Чо, не советуешь переходить на myisam?

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

тому шо советовать не видев системы особо нечего

Ну так, на то и форум, чтоб спросить, какой вариант будет лучше.

Сбор информации делал человек, не особо знакомый с этими БД. Я с ними не знаком вообще. Так что имеем что имеем, и думаем, как это сделать. Насчёт запросов ещё поспрашиваю, наверняка там можно что-то улучшить.

кто сказал Redis? :)

Там сбор статистики от виджета. Куда нажимали, сколько раз, какие движения мышью были и всё в этом роде. Потом данные используются для вывода статистики.

Выглядит как сбор текстовых логов, плюс нехитрый подсчет на коленке через пандас или hive.

Почему всегда нужно выпытывать подобную эту информацию? Почему все считают что у них прекрасное решение проблемы (не рабочее, лол), но которому не хватает одной маленькой детальки, типа покрутить настройки сервера и тогда все будет чики-пуки. Не будет, инфа соточка.

Но ведь в большинстве случаев так и есть, лол.

Если наш продакшен запустить на вдске с полгигом памяти, одним ядром и без настройки сервера - он одну страницу будет отдавать попытки с ...дцатой.

Если наш продакшен запустить на вдске с полгигом памяти, одним ядром и без настройки сервера - он одну страницу будет отдавать попытки с ...дцатой.

Херовый продакшен чо, который при потере кеша базы (рестарт или вымылся) тупит по пол дня. Знаем, плавали.

Какбе, при полгиге - там кэш толком ставить некуда, так что без него.

Для нормальной работы - нужно хотя бы пару гигов под тот же пул. А в идеале ещё отдельный сервак (или память на локальном) под редис.

Вопрос: можно ли перенести БД в ОЗУ? Какое решение будет наиболее оптимальным для продакшена?

Да просто на tmpfs положи, ведь с таким подходом данные продакшена явно не представляют никакой ценности

В myisam, если ничего не меняли, табличная блокировка, любой UPDATE лочит всю таблицу, оно тебе надо ?

Может, вам использовать какие-нибудь решения вида logstash?

Попробую посмотреть.

Судя по задаче, у тебя затык в одиночных параллельных инсертах, которые никто не любит (кроме специализированных баз данных), особенно InnoDB. С MyISAM/Maria было бы лучше.

Но ещё лучше - переписать апликацию. Как минимум, запись в базу сделать пакетированной. Т.е. приходящие данные не писать сразу, а складывать в очередь, а писать оттуда, блоками. С размером блока (количество вставленных рядов за раз) поиграешься сам. Оптимальные могут быть 100-10.000.

И учи матчасть, да. Если тебе SSD уже не помогает, то и in-memory не поможет без матчасти.

Вообще, это, конечно, гадание по кофейной гуще.

Начни с mytop, что б понимать, где затыки. Можешь глянуть mysqltuner, может он что посоветует. Может у тебя в таблице индексов дочерта лишних, часть которых можно убить без потери функциональности апликации (но с ускорением вставки инсертов). Ищи, короче, узкое место.

О каких объёмах вообще идёт речь? Сколько инсертов в секунду, сколько примерно размер одного ряда? Сколько индексов в таблице? Есть ли селекты одновременно с записью? Тяжелые ли они?

Насчёт матчасти - знаю, что надо учить. Опыта и знаний касательно БД нет вообще.

Сколько инсертов в секунду, сколько примерно размер одного ряда?

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

Почти все обращения - это INSERT и UPDATE.

Ну сколько там метрика с каждого сайта будет весить?

А хоть сколько она может весить. От байт до мегабайт.

сейчас запись идёт сразу тупо в базу, каждые 10 сек

Раз в 10 секунд один инсерт одного ряда? У тебя там метрики мегабайт по 100? Смори в mytop, что там тупит так.

Percona/MariaDB (XtraDB), ну и запросы оптимизированные.

Раз в 10 секунд один инсерт одного ряда? У тебя там метрики мегабайт по 100? Смори в mytop, что там тупит так.

Раз в 10 секунд приходят данные от пары десятков сайтов. Не, там явно не по 100 мбайт - менее 1 мбайта с сайта. Может в районе 100кбайт с каждого сайта.

запросы оптимизированные.

Пожалуй, это самая основная проблема, насколько я смог понять.

Начни с mytop, что б понимать, где затыки.

Нифига он не помогает, когда уйма мелких инсетов. У меня, вон, в секунду десятки записей + десятки чтений. MySQL заметно притормаживает систему, но в mytop почти всегда пустота. Даже когда qps на сотни идёт. Только просмотр бинлогов позволяет понять, что конкретно грузит.

Я в этом деле нупЪ, просто у нас сервак за сутки 2 раза упал.

Ееееееепт, и именно по этоому вы решили перенести базу в ОЗУ. Да вы знаете толк в сексе...

Ну я ж не говорил, что это лучший способ. Тем более уже выше по теме сказали, что с SSD толку не будет.