Сегодня я был на конференции» Производительность MySQL Спикером выступил Дмитрий Кравчук.
Спасибо.
Махамед , я уже знал 60% конференции.
Сама конференция была интересной, в хронографическом порядке рождения MySQL. С 1995 года, когда Монти и Дэвид объединились, до сегодняшних версий MySQL Perf. Что мне не понравилось:
- У Sun есть инсайдерская версия MySQL Perf (производительность чуть выше, чем в 5.4), которую выкатывать не торопится.
- «Солнце то, солнце то» можно было услышать почти на протяжении всей конференции.
- Мааткитом пренебрегли (может потому, что это была вражеская разработка?)
- Порадовал слушатель, в компании которого была «масштабируемая система» — 1500 запросов на 1 страницу.
При этом их технический руководитель считает memcache костылем.
- Бутербродов не было :(
- Оратор :).
Дмитрий ответил на все вопросы, была оживленная дискуссия.
В конце выступления были намеки, о которых я никогда раньше не слышал и нигде не видел.
- Принцип «Доверяй, но проверяй».
Дмитрий никому не доверял, поэтому тестировал работоспособность MySQL полностью сам.
- В комнате был человек из Перконы, который иногда помогал Дмитрию с ответами.
- MySQL развивается! Несмотря на покупку Sun, в последние годы производительности уделялось много внимания, что привело к выпуску версии 5.4.
- Каждое приложение уникально и сервер должен быть настроен под конкретные нужды (ваш КО)
- В настоящее время существует ошибка с innodb_max_dirty_pages_pct. Это значение просто игнорируется.
Патч есть, похоже в основную ветку его еще не добавили (могу ошибаться)
- Пока с innodb_max_dirty_pages_pct есть глюк, повлиять на сброс "грязных страниц" можно через innodb_log_file (не спрашивайте почему, спросите у Димы)
- Интересный вариант, о котором я раньше не слышал, — innodb_flush_log_trx_commit. Принимает значения 0, 1, 2. 0 — сброс каждую секунду (0 коммитов в секунду = 1 сброс), 1 — сброс каждого коммита (10 тысяч коммитов в секунду = 10 тысяч сбросов), 2 — сброс каждую секунду, если был коммит (10 тысяч коммитов в секунду = 1 флеш).
Лучший вариант по производительности естественно 2
- innodb_io_capacity — следует устанавливать в зависимости от возможностей жесткого диска.
Дмитрий предложил 2000
- Кэш запросов более 20 МБ — зло
- При включенном двойном буфере записи в некоторых случаях можно потерять до 30% производительности.
- Журнал повторов, журнал bin, буфер двойной записи должны храниться на разных жестких дисках из-за случайного чтения самой базы данных.
- Иногда стоит поиграться с max_purge_log
- Блог Дмитрия dimitrik.free.fr
-
Сколько Нужно Правообладателю?
19 Oct, 24
