innodb – Масштабируемость и новые возможности€¦ · innodb –...

Innodb – Масштабируемость и новые возможности

Peter ZaitsevPercona IncHighLoad.RU 2008Moscow, RussiaOct 6-7, 2008

-2-

Немного о Докладчике

• Основатель Percona Inc– Оптимизация

производительности, масштабируемость, надежность систем на MySQL

• Основатель http://www.mysqlperformanceblog.com

• Со-Автор “High Performance MySQL Second Edition

http://www.mysqlperformanceblog.com/

Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008

О чем эта презентация ?

• Innodb – наиболее популярная система хранения в MySQL

• Которая к сожалению не слишком хорошо масштабируется– Рассмотрим проблемы и их решения

• Посмотрим на другие аспекты производительности Innodb

• Фокус – существующий код MySQL 5.0 и 5.1• А так же сторонние данные.


Масштабируемость

• В широком смысле – масштабируемость приложения

• Задача – обеспечение нужной производительности за разумную стоимость– Есть так же требования по надежности безопасности

доступности итд• “Рост” приложения – размер базы данных чисто

запросов, часто их сложность.


Вопрос выживания или денег ?

• Многие системы спроектированы используя один сервер– Часто не за какие деньги невозможно купить сервер с

характеристиками нужными для роста– Максимальное использование ресурсов сервера

вопрос выживания• Другие системы могут использовать

произвольное число серверов с произвольной производительностью– Ее максимизация – вопрос эффективности


Масштабируемость роста

• Как ведет себя производительность при росте объема данных ?– Зачастую вопрос архитектуры/схемы баз данных– Поведение координально меняется когда данные

перестают влезать в память• Как ведет себя производительность при росте

сложности запросов ?– Понимать и контролировать сложность– Параллельное выполнение – Прегенерация данных итд


Масштабируемость железа

• Вопрос насколько большое приложение должно стать до того как потребуется использование многих серверов

• Вопрос эффективного использования– Всегда есть конфигурация с оптимальной ценой

производительностью– Важна возможность ее эффективного использования– Последние годы число ядер процессора в доступных

системах резко увеличилось и проблемы затрагивают все более широкие слои


Тестрировние Микро-Тестами

• Микро-Тесты Производительности – простые операции

• Тестирование какого-то определенного аспекта поведениия

• Проблемы найденые при них проявляются и в реальных приложениях– Однако они не раскрывают все проблемы разумеется

• Часто могут приувеличивать проблему– Может проявлятся в меньшей степени в реальных

приложениях


Не забудьте об обслуживании

• Часто забывают о требовании производительности обслуживания

• Очень важно для реально используемых приложений

• Обычно связаны с размером данных и потреблением ресурсов


Работа с большими объемами

• Сложны в обращении !• Резервное Копирование обязательно физическое• В Innodb таблицы нельзя перемешать между

серверами• Нет возможости REPAIR TABLE

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

• ALTER TABLE очень медленная – Master-Master репликация может помочь

• Обслуживание таблиц OPTIMIZE TABLE


Быстрое создание индексов

• MySQL 5.1 Innodb плагин от Oracle– Так же включен в MySQL 5.1 от Percona

• Innodb может создавать индексы без перестройки всей таблицы– И что важно с помошью сортировки

• Загрузка в 10 раз быстрее и более компактные индексы (специальный метод загрузки)

Метод загрузки Время Размер данных Размер индексаSQL Dump ٨٨m ١٣٣٣٧٨٨٦٧٢ ١٨٦٧٥١٣٨٥٦LOAD INFILE ٩٠m ١٣٣٣٧٨٨٦٧٢ ١٨٦٧٥١٣٨٥٦ALTER from MYISAM ٩٠m ١٣٣٣٧٨٨٦٧٢ ١٨٦٧٥١٣٨٥٦LOAD + ADD INDEX ٣m+٥m ١٣٣٣٧٨٨٦٧٢ ١١٢٤٠٧٣٤٧٢SQL Dump MyISAM ٣m ١٠٥٠٠٠٠٠٠٠ ٣١٢٥٧٩٠٧٢


Как сортировка влияет на индекс

• Индекс построеный с помошью сортировки физически сортирован и имеет большее заполнение страниц

• Полное Сканирование индекса (с диска)– 31 sec стандартный и 22 sec сортированный

• Процессор становится ограничивающим фактором

• Обновление ндекса:– update sample set c=md5(i) where i%1000=1;

• 3 min 20 sec стандертаны и 8 min 16 sec сортированый– Рост размера индекса

• 0% (стандартный) и 30% (сортированый)


Сжатие Данных

• Innodb расширение также имеет ф-ю сжатия данных– Постраничное сжатие без ограничение на обновление– Дополнительно большие BLOB/TEXT поля сжимаются

келиком– Много продвинутых технологий позволяющих делать

уделение и ряд обновлений без повторного сжатия– Балансировка сжатых и расжатых страниц в кэше – Несколько сложно в использовании

• “Угадай какое сжатие будет наиболее эффективно”


Много Таблиц

• Много маленьких таблиц часто может использоваться вместо одной большой– Innodb держит мета данные о всех таблиц к которым

было обращение в памяти что может занять много памяти. Не такая большая проблема для 64bit платформ

– innodb_file_per_table=1• Увеличивает потребление место маленькими таблицами• Если таблиц очень много то восстановление после сбоя может

быть очень долгим– “Разогрев” существенная таблица

• Открытие строго сериализовано (MySQL 5.0)• И медленное так как происходит обновление статистик


Работа с большим buffer pool

• Обычно чем больше buffer pool тем лучше• Расчитывайте на “Разогрев”

– Чем больше buffer pool тем он дольще– 32GB будет заполнятся 1 час

• При скорости чтения 600 страниц в сек

• Checkpoint активность может приводить к большим провалом производительности

• Иногда восстановление после сбоя происходит существенно медленнее с большим объемом кэша


Работа с большим Buffer pool

• Корректная остановка сервера занимает дольше времени– Все модифицированные страницы Buffer Pool должны

быть сохранены на диск– Установите innodb_max_dirty_pages_pct=0 заранее

чтобы почти все страницы были агрессивно сброшены.


Репликация

• Репликация отстает куда быстрее чем мастер или слейв полностью загружены– Все большая проблема с многоядерными проц-ами.– А так же когда нет BBU кэша в RAID на слейве

• Часто ограничено скоростью транзакций– установите innodb_flush_log_at_trx_commit=2

• Репликация то все равно асинхронно

• Ограничена скоростью собственно обновлений– Диск - префетчинг может помочь (кэш)– Процессор – смотрите row level replication в 5.1– Оптимизация траффика репликации


А теперь бенчмаки

Относитесь к результатам критично


Масштабируемость 5.0

• MySQL 5.0.51a• Dell PE 2950 • 2* Quad Core CPUs

– Intel Xeon L5335• Нет Дискового ввода

вывода• Масштабируемость

сильно зависит от нагрузки 1 4 16 64 256

0

1

2

3

4

5

6

7

1

2.51 2.42

1.56

1.191

2.85

4.29 4.25 4.21

1

3.53

5.95

4.73

3.63

1

2.66

3.81 3.8 3.8

1

2.2

1.87

1.1 1.09

KEY_RANGE KEY_POINT_IND PK_POINT_INDXFTS KEY_POINT

• Фактор масштабирования относительно числа потоков


Масштабируемость 5.1

• MySQL 5.1.23-rc• Все то же самое кроме

версии• Видно большое

падение производительности– Вроде исправлено в

5.1.28

1 4 16 64 2560

1

2

3

4

5

6

1

2.19

1.28

0.88

0.3

1

2.38

1.43 1.44 1.38

1

3.02

5.26

4.19

3.24

1

2.73

3.92 3.92 3.91

1

1.87

1.04

0.73

0.24

KEY_RANGE KEY_POINT_IND PK_POINT_INDXFTS KEY_POINT

• Фактор масштабируемости относительно числа потоков


Пр-сть одного потока

• Сложно судить только по фактору масштабирования

• Показываем скорость относительно 5.0.22

• 5.0.22 и 5.0.51 очень близки

• 5.1 показывает некоторую потерю производительности

KEY_RANGE KEY_POINT_IND PK_POINT_INDX FTS KEY_POINT0

0.2

0.4

0.6

0.8

1

1.2

1 1 1 1 10.97

1 0.99 0.99 0.99

0.9

0.82

1.04

0.96 0.94

5.0.22 5.0.51a 5.1.23

• Относительная производительнось разных версий


М-ость разных версий

• Фактор масштабирования для 64 потоков

• MySQL 5.0.51 лучшие результаты

• Заметные улучшения относительно 5.0.22

• 5.1 медленнее (возможно исправлено) KEY_RANGE KEY_POINT_IND PK_POINT_INDX FTS KEY_POINT

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

0.2

2.42

4.48

2.49

0.18

1.61

4.23

4.72

3.78

1.14

0.88

1.44

4.19

3.93

0.73

5.0.22 5.0.51a 5.1.23

• Фактор масштабирования разных версий MySQL


innodb_thread_concurrency

• Производительность для 64 потоков

• MySQL 5.1.23 innodb_thread_concurrency=0 - база

• Нет лучшего значения для всех типов нагрузки

KEY_RANGE KEY_POINT_IND PK_POINT_INDX FTS KEY_POINT0

0.5

1

1.5

2

2.5

1 1 1 1 1

2.07

0.53

1

0.7

2.21

2.06

0.49

1.050.98

2.03

innodb_thread_concurrency=0



• Как innodb_thread_concurrency влияет не производительность


Fixing scaling by CPU Affinity

• Performance for 16 threads

• MySQL 5.1.23– 5.0.51a for comparison

• Workloads which scaled worse on 5.1.23

• Trying to bind MySQL to specific CPU Cores

• Restricting can help scaling

KEY_POINT_INDX KEY_POINT KEY_RANGE_INDX KEY_RANGE0

0.5

1

1.5

2

2.5

3

3.5

4

1 1 1 10.97

1.72

0.91

2.39

1.16

1.72

1.04

2.65

0.97

1.89

0.61

1.68

0.99

1.28

0.61

1.68

3.63

1.93

2.27

3.01

4x4 2x2 4x0 1x1 2x0 5.0.51

• How binding to CPUs affects performance


Quadcore vs Dual Core

• MySQL 5.1.23rc• Нагрузки которые

плохо масштабируются• 2 из 3х типов нагрузки

лучше ведут себя на 2*Dual Core сситеме

1 4 16 64 2560

0.5

1

1.5

2

2.5

3

3.5

1

1.87

1.04

0.73

0.24

1

2.07

1.89

1.75

1.45

1

2.19

1.28

0.88

0.3

1

2.44

2.16

2

1.68

1

2.61

2.89 2.942.84

1

2.722.78 2.73

2.63

POINT 8 POINT 4 RANGE 8RANGE 8 RANGE_IDX 8 RANGE_IDX 4

• Масштабируемость и число ядер


Large Pages

• MySQL can use Large Pages for Innodb Buffer Pool

• Huge Pages reduce TLB cache misses

• Non Swapable• Mediocre results for this

workload, may be better in case of skewed working set

1 4 16 640

0.2

0.4

0.6

0.8

1

1.2

1.4

1.2

11.05 1.05

1.08

1.02 1 10.96

1 1 1

FTS KEY_RANGE POINT_INDEX

• Performance effect of using Large Pages


Innodb – Масштабируемость IO

• Dell PowerEdge 2950, Perc6, CentOS 5.0

• RAID1 иRAID10 (6 disk)

• SysBench тест

RAID1 RAID100

20

40

60

80

100

120

140

160

21

62

42

139

RW RO

• Масштабируемость RAID


EXT3 и EXT2

• То же самое железо• RAID10 • Ext3 хуже на запись

(оверхед на журналирование) но несколько лучше на чтение.

EXT2 EXT30

20

40

60

80

100

120

140

160

69

62

129

139

RW RO

• Производительность Файловых систем


Linux планировщики I/O

• Улучшились за последние годы– Разница не такая

большая как несколько лат назад

• CFQ (стандартный) дает лучшую производительность в этом случае

CFQ DEADLINE AS NOOP0

20

40

60

80

100

120

140

160

62 63

5660

139

116112

137

RW RO

• Performance effect of using Large Pages


Будущее Innodb

• Oracle продолжает вести работы– В страшной секретности и не раскрывает планов

• Community берет развитие в свои руки– Google (Mark Callaghan) выпустили патчи улучшающие

производительность на ряде операций• На некоторых других производительность падает

• Yasufumi – множество патчей улучшающих масштабируемость

• Percona - Патчи/релизы – Улучшение производительности– Анализ производительности


Спасибо что пришли !

• Время для вопросов• Пишите

– [email protected] • Приходите к нам

– За информацией: http://www.mysqlperformanceblog.com– За помошью: http://www.percona.com

mailto:[email protected]

http://www.mysqlperformanceblog.com/

http://www.percona.com/

innodb – Масштабируемость и новые возможности€¦ · innodb –...

Documents