Percona MySQL Server
Как Вы знаете, движок таблиц InnoDB в MySQL стал платным. Теперь пакетные бесплатные версии этой СУБД поставляются только с MyISAM, Memory и несколькими другими движками. InnoDB по-умолчанию теперь не установлен.
Движок InnoDB в MySQL остается бесплатным (опять включен в 5.5), но судя по всему поддержка и развитие community версии будет идти с большим опозданием.
Парни из компании Percona уже давно делают свою собственную сборку сервера, в которой установлен продвинутый движок XtraDB (на базе InnoDB). Посмотрим поближе на этот продукт.
XtraDB
XtraDB - это усовершенствованный движок InnoDB с большим количеством улучшений. Среди особенностей следует отметить:
- Больше параметров для более тонкой настройки
- Больше параметров и возможностей для сбора статистики (например, лог медленных запросов менее секунды)
- Более эффективное управление памятью
- Более эффективная работа на большом количестве ядер
Самое главное, что разработчики делали изменения на основе реальных запросов от клиентов, которые испытывали трудности в практических условиях. Этот движок поставляется бесплатно в рамках сборки Percona Server.
Особенности сервера
Эта сборка MySQL сервера включает большое количество полезных дополнений и изменений.
XtraDB
В сборку входит продвинутый движок XtraDB.
NoSQL интерфейс
В версии 5.5.8 ребята планируют добавить сокет-интерфейс для прямой работы с данным в обход протокола SQL. Очень круто!
Большое число параметров диагностики
Сбор статистики производительности в разрезе на клиента, таблицу, индекс, пользователя. Очень полезная информация для решения проблем с быстродействием.
Улучшения в проиводительности
Большое число оптимизаций для более эффективной работы сервера. Например, быстрое выключение, предзагрузка буферного пула, быстрые алгоритмы контрольных сум, неблокирующие алгоритмы и множество других изменений.
Практический опыт
Недавно установили этот сервер на один из быстро растущих проектов. Была необходимость перехода на InnoDB, т.к. с удивлением обнаружили, что мы работали на MyISAM, и начались проблемы из-за постоянных блокировок. Удивительно, что MySQL при поднятии из дампа не ругался на то, что не знает движка InnoDB, а просто присвоил всем таблицам MyISAM.
Установка очень простая, т.к. для популярных сборок линукса на сервере есть пакеты. База стала без проблем. Поднялись с дампа (порядка 100 таблиц), все заработало с первого раза. Сейчас нагрузка небольшая - 300 запросов в секунду (500 в пики). Мощный сервер на 32Гб и 8 ядер отдыхает.
Откуда инфа что InnoDB стал платным? GPL 2 остался.
http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html
Да, в новой версии InnoDB опять включен в комьюнити-упаковку (не знал этого). В любом случае очень советую посмотреть на XtraDB.
спасибо, за инфу. заценим.
> В сборку входит продвинутый движок XtraDB.
Наверное, так: “… продвинутый движок InnoDB”
Сейчас работаем под MySQL, на сервере “Quad-Core, 8GB”. Нагрузка средняя 400 запросов в секунду (до 700 в пики). Apache и MySQL на одном сервере. Уже подобрались к критической нагрузке в пиковое время. Думаем переходить в самом скором времени на Percona. Сервер берём только под DB. Посчитали-прикинули и вышло, что “Intel® Core™ i7-920 Quad-Core, 12GB” “за глаза хватит”. Рассчитывали-прикидывали 5-кратное увеличение нагрузки.
Вы тестируете-работаете Percona на “32Гб и 8 ядер”(хоть он и отдыхает). Не слишком ли вы с сервером замахнулись или мы что-либо “просчитали”?
Мы выбирали конфигурацию сервера на основе объема наших данных, которые целиком занимают приблизительно столько, сколько уместит в себя оперативная память. В этом случае мы не будем сталкивать с проблемами чтения с диска.
Вообще выбирать конфигурацию сервера нужно именно на основе объема данных и типов запросов, а не их кол-ва в секунду. Т.к. MySQL способен обслуживать тысячи (и даже десятки) запросов в секунду при условии, что ему хватает памяти и запросы хорошо оптимизированы.
> … выбирать конфигурацию сервера нужно именно на основе объема данных …
Бесспорно. НО, не вернее-ли будет “.. основе объема ИНДЕКСОВ …”.
Основная работа будет сделана по индексам - “супер быстро”, т.к. они в памяти, а уже по результатам выборки будут собраны данные - также “супер быстро”(даже и из диска), т.к. они будут наверняка выбираться по ID и их уже(после выборки) будет немного(относительно).
P.S. НО это я не спорю,
просто сейчас сами выбираем оптимальный сервер и так вот рассуждаем.
> “… нужно именно на основе объема данных …”
не вернее ли будет “на основе объема ИНДЕКСОВ”?
Не вернее, т.к. делать случайные чтения с диска - это ВСЕГДА ОЧЕНЬ ДОРОГО. Тем более, если у Вас не маленькие по длине записи. Если у Вас 400 запросов в секунду, то прикиньте сколько Вы будете вызывать чтений с диска в течении секунды.
Коллеги, а переехать на Percona c Mysql можно без дампа и заливки данных? старые базы оно подхватит?
Мы запускались в новой папке данных и переливали данные через дамп. Не уверен, но возможно будет работать и со старыми файлами данных и логами, т.к. в формате никаких изменений быть не должно. В любом случае пробовать нужно с готовыми бекапами.
Спасибо.
Сервер вот такой:
2x AMD Opteron 2344 HE, 2x Quad-Core
8 GB DDR2-RAM ECC
баз данных около 120штук, примерно равномерно в каждую в день добавляется по 1000 строк в одну таблицу myisam (сопровождается это всё апдейтами и селектами) + есть несколько тяжелых селектов, в итоге в секунду примерно 200 запросов. размер баз 300-900мБ
в текущей ситуации работает всё это не быстро. процессор отдыхает, а приложение тормозит.
на постгре ситуация с использованием процессора гораздо лучше, но переписывать нет возможности.
я правильно понимаю что XtraDB или хотябы InnoDB спасёт ситуацию?
Все зависит от того, в чем причина проблем. Если у Вас процессор ждет дисков (iowait) - тогда Вы уперлись в чтения или запись на диск. Возможно большинство времени проходит в ожидании освобождения блокировок на чтение или запись. Это нужно померять. 1000 вставок в день - это довольно мало. Если это действительно так, то переходить на innodb нет смысле, т.к. d MyISAM немного быстрее работают выборки и размер самих баз существенно меньше. Нужно также померять обновления и удаления. Если их много - переключайтесь на innodb.
iotop установил завтра гляну.
я что-то неверную цифру вставок сказал - поглядел в счетчики:
select - 23k в час 5% запросов
update - 115k в час 20% запросов
insert - 23к в час 5% запросов
есть еще
set option - 23% и change db - 23%
нашел лог примерно в часы нагрузки 11.4%wa - это много?
@Viktor подхватит
Вообще handler socket у нас и в сборках на 5.1 есть
Handler Socket доступен в 5.1 тоже
@Viktor
поставьте Percona-Server и посмотрите на response-time-distribution
http://www.percona.com/docs/wiki/percona-server%3Afeatures%3Aresponse_time_distribution
@Viktor: вообще, как вижу вашу ситуацию (поверхностно и по-быстрому, конечно), проблема у вас в логике приложения. В принципе, количество SQL-Statements невелико, Hardware достаточно и с нормальной логикой приложения инастройками тормозить не должно.
Исходя из цифр:
> select - 23k в час 5% запросов
> update - 115k в час 20% запросов
> insert - 23к в час 5% запросов
Однозначно бы посоветовал переходить на InnoDB, т.к. write-SQL-запросов у вас много(в % к общему числу).
Посмотрите(максимально увеличте) значения innodb_buffer_pool и key_buffer
Важное значение, конечно же и всегда, имеют индексы. Соптимируйте их.
> несколько тяжелых селектов
их быть, конечно, не должно. Облегчить их, по-возможности, нужно(можно) индексами и(или) “переносом” логики в приложение.