innodb – Масштабируемость и новые возможност舦 · innodb –...
TRANSCRIPT
Innodb – Масштабируемость и новые возможности
Peter ZaitsevPercona IncHighLoad.RU 2008Moscow, RussiaOct 6-7, 2008
-2-
Немного о Докладчике
• Основатель Percona Inc– Оптимизация
производительности, масштабируемость, надежность систем на MySQL
• Основатель http://www.mysqlperformanceblog.com
• Со-Автор “High Performance MySQL Second Edition
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
О чем эта презентация ?
• Innodb – наиболее популярная система хранения в MySQL
• Которая к сожалению не слишком хорошо масштабируется– Рассмотрим проблемы и их решения
• Посмотрим на другие аспекты производительности Innodb
• Фокус – существующий код MySQL 5.0 и 5.1• А так же сторонние данные.
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Масштабируемость
• В широком смысле – масштабируемость приложения
• Задача – обеспечение нужной производительности за разумную стоимость– Есть так же требования по надежности безопасности
доступности итд• “Рост” приложения – размер базы данных чисто
запросов, часто их сложность.
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Вопрос выживания или денег ?
• Многие системы спроектированы используя один сервер– Часто не за какие деньги невозможно купить сервер с
характеристиками нужными для роста– Максимальное использование ресурсов сервера
вопрос выживания• Другие системы могут использовать
произвольное число серверов с произвольной производительностью– Ее максимизация – вопрос эффективности
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Масштабируемость роста
• Как ведет себя производительность при росте объема данных ?– Зачастую вопрос архитектуры/схемы баз данных– Поведение координально меняется когда данные
перестают влезать в память• Как ведет себя производительность при росте
сложности запросов ?– Понимать и контролировать сложность– Параллельное выполнение – Прегенерация данных итд
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Масштабируемость железа
• Вопрос насколько большое приложение должно стать до того как потребуется использование многих серверов
• Вопрос эффективного использования– Всегда есть конфигурация с оптимальной ценой
производительностью– Важна возможность ее эффективного использования– Последние годы число ядер процессора в доступных
системах резко увеличилось и проблемы затрагивают все более широкие слои
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Тестрировние Микро-Тестами
• Микро-Тесты Производительности – простые операции
• Тестирование какого-то определенного аспекта поведениия
• Проблемы найденые при них проявляются и в реальных приложениях– Однако они не раскрывают все проблемы разумеется
• Часто могут приувеличивать проблему– Может проявлятся в меньшей степени в реальных
приложениях
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Не забудьте об обслуживании
• Часто забывают о требовании производительности обслуживания
• Очень важно для реально используемых приложений
• Обычно связаны с размером данных и потреблением ресурсов
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Работа с большими объемами
• Сложны в обращении !• Резервное Копирование обязательно физическое• В Innodb таблицы нельзя перемешать между
серверами• Нет возможости REPAIR TABLE
– При повреждениях часто приходится загружать таблицу из дампа, часто быстрее восстановить все из бакапа
• ALTER TABLE очень медленная – Master-Master репликация может помочь
• Обслуживание таблиц OPTIMIZE TABLE
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Быстрое создание индексов
• 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 ١٠٥٠٠٠٠٠٠٠ ٣١٢٥٧٩٠٧٢
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Как сортировка влияет на индекс
• Индекс построеный с помошью сортировки физически сортирован и имеет большее заполнение страниц
• Полное Сканирование индекса (с диска)– 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 — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Сжатие Данных
• Innodb расширение также имеет ф-ю сжатия данных– Постраничное сжатие без ограничение на обновление– Дополнительно большие BLOB/TEXT поля сжимаются
келиком– Много продвинутых технологий позволяющих делать
уделение и ряд обновлений без повторного сжатия– Балансировка сжатых и расжатых страниц в кэше – Несколько сложно в использовании
• “Угадай какое сжатие будет наиболее эффективно”
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Много Таблиц
• Много маленьких таблиц часто может использоваться вместо одной большой– Innodb держит мета данные о всех таблиц к которым
было обращение в памяти что может занять много памяти. Не такая большая проблема для 64bit платформ
– innodb_file_per_table=1• Увеличивает потребление место маленькими таблицами• Если таблиц очень много то восстановление после сбоя может
быть очень долгим– “Разогрев” существенная таблица
• Открытие строго сериализовано (MySQL 5.0)• И медленное так как происходит обновление статистик
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Работа с большим buffer pool
• Обычно чем больше buffer pool тем лучше• Расчитывайте на “Разогрев”
– Чем больше buffer pool тем он дольще– 32GB будет заполнятся 1 час
• При скорости чтения 600 страниц в сек
• Checkpoint активность может приводить к большим провалом производительности
• Иногда восстановление после сбоя происходит существенно медленнее с большим объемом кэша
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Работа с большим Buffer pool
• Корректная остановка сервера занимает дольше времени– Все модифицированные страницы Buffer Pool должны
быть сохранены на диск– Установите innodb_max_dirty_pages_pct=0 заранее
чтобы почти все страницы были агрессивно сброшены.
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Репликация
• Репликация отстает куда быстрее чем мастер или слейв полностью загружены– Все большая проблема с многоядерными проц-ами.– А так же когда нет BBU кэша в RAID на слейве
• Часто ограничено скоростью транзакций– установите innodb_flush_log_at_trx_commit=2
• Репликация то все равно асинхронно
• Ограничена скоростью собственно обновлений– Диск - префетчинг может помочь (кэш)– Процессор – смотрите row level replication в 5.1– Оптимизация траффика репликации
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
А теперь бенчмаки
Относитесь к результатам критично
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Масштабируемость 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
• Фактор масштабирования относительно числа потоков
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Масштабируемость 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
• Фактор масштабируемости относительно числа потоков
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Пр-сть одного потока
• Сложно судить только по фактору масштабирования
• Показываем скорость относительно 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
• Относительная производительнось разных версий
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
М-ость разных версий
• Фактор масштабирования для 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 — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
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=4
innodb_thread_concurrency=8
• Как innodb_thread_concurrency влияет не производительность
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
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
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
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
• Масштабируемость и число ядер
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
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 — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
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
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
EXT3 и EXT2
• То же самое железо• RAID10 • Ext3 хуже на запись
(оверхед на журналирование) но несколько лучше на чтение.
EXT2 EXT30
20
40
60
80
100
120
140
160
69
62
129
139
RW RO
• Производительность Файловых систем
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
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 — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Будущее Innodb
• Oracle продолжает вести работы– В страшной секретности и не раскрывает планов
• Community берет развитие в свои руки– Google (Mark Callaghan) выпустили патчи улучшающие
производительность на ряде операций• На некоторых других производительность падает
• Yasufumi – множество патчей улучшающих масштабируемость
• Percona - Патчи/релизы – Улучшение производительности– Анализ производительности
Innodb — Масштабируемость и новые возможности, HighLoad.ru, , Moscow, Russia Oct 6-7 2008
Спасибо что пришли !
• Время для вопросов• Пишите
– [email protected] • Приходите к нам
– За информацией: http://www.mysqlperformanceblog.com– За помошью: http://www.percona.com