Сегодня был на конференции "Производительность MySQL". Докладчик был Дмитрий Кравчук. Спасибо maghamed, 60% конференции я уже знал.
Сама конференция была интересной, в хронографическом порядке зарождения MySQL. Начиная от 1995 года, когда собрались Монти и Дэвид, до сегодняшнего дня, MySQL Perf версии.
Что не понравилось:

• Sun имеет инсайдерскую версию MySQL Perf (производительность чуть выше чем в 5.4), которую не спешит выкатывать.
• Почти всю конференцию было слышно «Sun это, Sun то».
• Обделили maatkit вниманием (может потому что вражеская разработка?)
• Порадовал слушатель, в компании которого была «масштабируемая система» — 1500 запросов на 1 страницу. При этом их техлид считает memcache костылями.
• Не было бутербродов :(

Что понравилось:

• Докладчик :). Дмитрий отвечал на все вопросы, было живое обсуждение. В конце выступления пошли хинты, про которые я до этого не слышал и нигде не видел.
• Принцип «Доверяй, но проверяй». Дмитрий не верил никому, поэтому полностью сам тестил MySQL в производительности.
• В зале был человек от Percona, который иногда помогал Дмитрию с ответами.
• 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
• Query cache больше 20мб — зло
• С включенным double write buffer в некоторых случаях можно потерять до 30% производительности
• Redo log, bin log, Double Write buffer стоит хранить на разных винчестерах из-за random read для самой базы
• Иногда стоит поиграться с max_purge_log
• Блог Дмитрия dimitrik.free.fr

Chromium создал новую технологию компресии диффов под названием Courgette. Courgette занимает в 9 раз меньше места по сравнению с аналогами (diff, bsdiff), благодаря новому алгоритму хранения диффов.
Техническую часть можно найти здесь. Интересно то, что в Google Chrome используют молчаливые апдейты. Т.е. я уже не решаю для своего браузера когда же ему обновляться. Нехорошо. Хорошо, что новая технология будет открытая.
Ура open source!

via slashdot.org