Mysql Percona Server 5.6 vs MariaDB 10.0 под нагрузкой

Yoskaldyr

"Спамер"
Партнер клуба
Я понимаю что ответ зависит полностью от задач, но просто интересно кто что использует
марию или перкону под нагрузкой и под какими задачами (много простых запросов / много инсертов / т.п.).
А особенно интересно если у кого есть базы с нагрузкой более 1K qps и размером более 8Г (данные + индекс)
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
чем вызван вопрос? у них разница в шлюхах, а код исполнения основных операций у них у всех практически одинаковый
 

Yoskaldyr

"Спамер"
Партнер клуба
в том то и дело что ведут себя не одинаково.

Юзкейс - куча простых запросов на чтение по индексу с джойнами тоже по индексу. Относительно немного вставок.
И очень редко тяжелые запросы на чтение (фулскан на несколько гиг).
Т.е. скорость выполнения этих тяжелых запросов не сильно важна, но важно чтобы в этот момент все остальное продолжало работать если и притормаживало то не существенно.
Так вот эти запросы перкона переваривает нормально, т.е. все остальное работает в пределах нормы, а в марии все запросы в этот момент начинает выполняться значительно медленнее.
На лицо явна различная работа с буфер пулом, т.к. на перконе он забивается на 100% где-то за пару суток, на марии максимальное заполнение было около 60% за пару недель.

Настройки сервера связанные с innodb (данных с индексами около 10гиг)
Код:
innodb_buffer_pool_size=24G
innodb_file_per_table=1
innodb_file_format=barracuda
innodb_flush_log_at_trx_commit=2
innodb_old_blocks_time=2000
innodb_thread_concurrency=0
И дело не в innodb_old_blocks_time, при установке в 0, в марии как и в перконе буфер пул забивается на 100% за пару часов, но общие периодические тормоза в марии не пропадают.
Сервер мощный на 2 топовых проца, памяти 128 гиг, т.е. дело не в нехватке мощностей.
И дело не в настройке Numa, точное распределение по процам не дало нужного эффекта.

Скорее всего связано с остальными настройками по умолчанию для innodb что различаются в перконе и в марии, но сравнивать значение по умолчанию от версии к версии - как совсем не хочется.
Читал что перкона по своему работает с совместным доступом у пулу, т.е. для перконы innodb_buffer_pool_instances не имеет смысла, вернее работать то работает, но смысла включать нет. Может еще с этим связано.

Почему не выбрать перкону если все в ней нравится? Нужен модуль сфинкса. Мария же привлекает тем что не надо париться со сборкой модуля под сфинкс, и есть другие готовые бинарные пакеты именно под марию. Перкона напрягает ручной сборкой всего стороннего что не идет в комплекте, который по сравнению с марией довольно таки скуден и чтобы собрать что-то иногда надо довольно долго плясать с бубном.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Такие вещи, как работа с буферами, локи, планировщик запросов у всех разные, и меняются они даже в минорных версиях,
проверь планы исполнения тяжелых запросов, количество считываемых строк.

Если у тебя innodb_buffer_pool_size в 2 раза больше данных, я думаю, там проблема в локах.

Тяжелые запросы стоит вынести на слейв, обычно так делают.

"есть готовые бинарные пакеты" на этом уровне проблем уже несерьезно. Если ты лезешь в такие тонкости, как innodb_old_blocks, собрать что-то ручками - вообще элементарная операция. На решение этой задачи уйдут дни, а сборка из исходников - вопрос часов.
 

Yoskaldyr

"Спамер"
Партнер клуба
Такие вещи, как работа с буферами, локи, планировщик запросов у всех разные, и меняются они даже в минорных версиях,
проверь планы исполнения тяжелых запросов, количество считываемых строк.
План запросов идентичен (серьезный скан от 300К до 2KK строк с соответствующей нагрузкой на io), и скорость приблизительно одинаковая, но вот общее проседание всего остального очень и очень различное.
Если у тебя innodb_buffer_pool_size в 2 раза больше данных, я думаю, там проблема в локах.
Может, но по слоуквери логу для всех обычных быстрых запросов, которые в этот момент начинают тупить локтайм в этот момент минимальный, но вот скорость самого запроса больше 6-7сек, а обычно >0.005сек. Вот почему предположение о разной работе с innodb pool-ом (только предположение).
Тяжелые запросы стоит вынести на слейв, обычно так делают.
Я стараюсь найти решение оптимальное по трудозатратам, выносить такие запросы на слейв - это переписывать чужой код и переписывать в дальнейшем при обновлении этого кода.
"есть готовые бинарные пакеты" на этом уровне проблем уже несерьезно. Если ты лезешь в такие тонкости, как innodb_old_blocks, собрать что-то ручками - вообще элементарная операция. На решение этой задачи уйдут дни, а сборка из исходников - вопрос часов.
я не говорю что это проблема собрать - говорю, что напрягает.
И раз от раза даже в минорных версиях что-то ломается при сборке - приходится день или два разбираться чтобы выяснить что это опять какой-то баг который вылез из-за того что сейчас мария использует CPackRPM, а не стандартные утилиты для сборки rpm. Часто исходники сторонних модулей заточены под хедеры или марии или ванильного мускуля (перкона по хедерам ближе к ванильному, но все равно не одно и тоже). Как следствие бывают небольшие косяки в исходниках плагинов как раз связанные со сборкой под конкретный форк. Например, с полгода назад нормально собрать mroonga под перкону так и не получилось (хотя сейчас могло что-то поменяться).
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
я имел ввиду не число строк в explain, а число считанных строк в счетчиках
и не про локи на уровне таблицы, а про разделяемую память и мультипоточное взаимодействие

Я стараюсь найти решение оптимальное по трудозатратам, выносить такие запросы на слейв - это переписывать чужой код и переписывать в дальнейшем при обновлении этого кода.
думаю, необязательно, можно настроить mysql balancer (prox, haproxy, galera) чтобы на слейв уходили избранные скрипты
 
Последнее редактирование:

Yoskaldyr

"Спамер"
Партнер клуба
я имел ввиду не число строк в explain, а число считанных строк в счетчиках
Если о performance schema, то да не сравнивал значения у двух баз :(
и не про локи на уровне таблицы, а про разделяемую память и мультипоточное взаимодействие
к этому тоже склоняюсь
думаю, необязательно, можно настроить mysql balancer (prox, haproxy, galera) чтобы на слейв уходили избранные скрипты
покопаю в этом направлении, но проще думаю заставить нормально работать 1 инстанс базы учитывая что мощностей хватает, чем пытаться поднимать балансировку
 

fixxxer

К.О.
Партнер клуба
Можно запариться с исследованием причин, но я бы на твоем месте не парился и собрал пакеты с теми версиями, на которых все хорошо. Тем более что в mysql и его форках в таких нюансах зачастую все меняется даже в минорном билде, и разумно зафиксировать "хорошую" версию в собственном репозе. Да и сборку обычно есть кому поручить, админ же есть, наверное.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
реплика на серьезном проекте нужна независимо от производительности для failover, обсчета статистики, бекапа
 

Yoskaldyr

"Спамер"
Партнер клуба
в том то и дело что проект средней серьезности и в нем нет ни постоянного программиста ни постоянного админа (даже при такой посещалке и таких нагрузках). Я периодически смотрю какие там узкие места, и что можно подправить и затюнить с минимальными усилиями.
Насчет зафиксировать какую-то версию мускуля - это идея, как-то даже не подумал :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
тысяча запросов на выборку в секунду - нагрузка большая, но нормальная, и это неважно, решает количество денег, которые потеряются при остановке на день
 
Последнее редактирование:

Yoskaldyr

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

Останавливаюсь на варианте один раз собрать все под перконой и забить на обновление перконы :)
 
Последнее редактирование:
Сверху