Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Федор Сигаев (Postgres Professional), Света Смирнова, Анастасия Распопина (Percona)
1 like1,566 views
Документ обсуждает производительность и оптимизацию различных реляционных баз данных, особенно MySQL и PostgreSQL, с акцентом на сравнительный анализ их возможностей. Проводятся тесты производительности, детально описываются проблемы и трудности, с которыми сталкиваются пользователи, а также предлагются различные конфигурационные решения для улучшения работы систем. Также упоминаются достижения и новшества в области разработки и поддержки данных СУБД с упором на использование ресурсов и управление транзакциями.
![∙
vm.swappiness=1
∙
cpupower frequency-set –governor performance
∙
kernel.sched_autogroup_enabled=0
∙
kernel.sched_migration_cost_ns= 5000000
∙ vm.dirty_background_bytes=67108864
∙ vm.dirty_bytes=536870912
∙ IO scheduler [deadline]
Системная конфигурация
11](https://image.slidesharecdn.com/2-161114152613/85/Open-Source-SQL-Postgres-Professional-Percona-21-320.jpg)
![LD_PRELOAD=/data/sveta/5.7.14/lib/mysql/libjemalloc.so
/data/sveta/sbkk/bin/sysbench
[–test=/data/sveta/sysbench/sysbench/tests/db/oltp_prepared.lua |
–test=/data/sveta/sysbench/sysbench/tests/db/oltp_simple_prepared.lua ]
–db-driver=mysql –oltp-tables-count=8 –oltp-table-size=10000000
–mysql-table-engine=innodb –mysql-user=msandbox
–mysql-password=msandbox –mysql-socket=/tmp/mysql_sandbox5715.sock
–num-threads=$i –max-requests=0 –max-time=300 –percentile=0
[–oltp-read-only=on –oltp-skip-trx=on ]
run
Параметры sysbench
13](https://image.slidesharecdn.com/2-161114152613/85/Open-Source-SQL-Postgres-Professional-Percona-27-320.jpg)
![∙ Проблема: обработка NULL для PostgreSQL сломана в
sysbench.
[fontsize=]
FATAL: failed to execute function ‘event’: 3
(last message repeated 7 times)
FATAL: PQexecPrepared() failed: 7 ERROR: invalid input syntax for integer:
∙ Починено. Алексей Копытов смёржил pull request.
[fontsize=]
/* Convert SysBench bind structures to PgSQL data */
for (i = 0; i < (unsigned)pgstmt->nparams; i++)
{
- if (stmt->bound_param[i].is_null)
+ if (stmt->bound_param[i].is_null && *(stmt->bound_param[i].is_null))
continue;
switch (stmt->bound_param[i].type) {
sysbench и prepared statements: попытка 1
30](https://image.slidesharecdn.com/2-161114152613/85/Open-Source-SQL-Postgres-Professional-Percona-64-320.jpg)
![∙ Проблема 2: sysbench не может нагрузить PostgreSQL, когда
используются prepared statements.
[fontsize=]
93087 korotkov 20 0 9289440 3,718g 2964 S 242,6 0,1 0:32.82 sysbench
93161 korotkov 20 0 32,904g 81612 80208 S 4,0 0,0 0:00.47 postgres
93116 korotkov 20 0 32,904g 80828 79424 S 3,6 0,0 0:00.46 postgres
93118 korotkov 20 0 32,904g 80424 79020 S 3,6 0,0 0:00.47 postgres
93121 korotkov 20 0 32,904g 80720 79312 S 3,6 0,0 0:00.47 postgres
93128 korotkov 20 0 32,904g 77936 76536 S 3,6 0,0 0:00.46 postgres
93130 korotkov 20 0 32,904g 81604 80204 S 3,6 0,0 0:00.47 postgres
93146 korotkov 20 0 32,904g 81112 79704 S 3,6 0,0 0:00.46 postgres
..............................................................................
∙
...решено пока забить на sysbench и пользоваться pgbench!
sysbench и prepared statements: попытка 2
31](https://image.slidesharecdn.com/2-161114152613/85/Open-Source-SQL-Postgres-Professional-Percona-65-320.jpg)
![Всё на github’е и воспроизводится!
[fontsize=]
$ git clone https://github.com/postgrespro/pg_oltp_bench.git
$ cd pg_oltp_bench
$ make USE_PGXS=1
$ sudo make USE_PGXS=1 install
$ psql DB -f oltp_init.sql
$ psql DB -c "CREATE EXTENSION pg_oltp_bench;"
$ pgbench -c 100 -j 100 -M prepared -f oltp_ro.sql -T 300 -P 1 DB
$ pgbench -c 100 -j 100 -M prepared -f oltp_rw.sql -T 300 -P 1 DB
Как его запускать?
34](https://image.slidesharecdn.com/2-161114152613/85/Open-Source-SQL-Postgres-Professional-Percona-68-320.jpg)
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Федор Сигаев (Postgres Professional), Света Смирнова, Анастасия Распопина (Percona)
- 1. OpenSource SQL Databases Enter Millions Queries per Second EraАнастасия Распопина, Света Смирнова, Александр Коротков, Фёдор Сигаев 8 ноября 2016
- 2. ∙ Инженер тех. поддержки MySQL ∙ Автор ∙ MySQL Troubleshooting ∙ JSON UDF функции ∙ FILTER clause для MySQL ∙ Докладчик ∙ Percona Live, OOW, Fosdem, DevConf, ... Света Смирнова 2
- 3. ∙ Speakers at PGCon, PGConf: 20+ talks∙ GSoC mentors∙ 3 PostgreSQL major contributors + 1 committer∙ Conference organizers∙ 50+ years of PostgreSQL expertship: dev., audit, consult.∙ Postgres Professional company co-founders PostgreSQL CORE∙ Locale support∙ PostgreSQL extendability: GiST(KNN), GIN, SP-GiST∙ Full Text Search (FTS) ∙ NoSQL (hstore, jsonb)∙ Indexed regexp search ∙ Access method extendability Extensions∙ intarray∙ pg_trgm∙ ltree ∙ hstore∙ plantuner ∙ jsquery Russian developers of PostgreSQL: Alexander Korotkov, Teodor Sigaev, Oleg Bartunov 3
- 4. MySQL
- 5. ∙ Для меня всё могло быть просто Со стороны MySQL 5
- 6. ∙ Для меня всё могло быть просто ∙ Дмитрий регулярно публикует детальные результаты тестов Со стороны MySQL 5
- 7. ∙ Для меня всё могло быть просто ∙ Дмитрий регулярно публикует детальные результаты тестов ∙ Александр мог прогнать их на PostgreSQL Со стороны MySQL 5
- 8. ∙ Для меня всё могло быть просто ∙ Оригинальная цель исследования ∙ Многие клиенты используют несколько БД ∙ Как правило хорошо знают только одну ∙ Общие проблемы Со стороны MySQL 5
- 9. ∙ Для меня всё могло быть просто ∙ Оригинальная цель исследования ∙ Многие клиенты используют несколько БД ∙ Как правило хорошо знают только одну ∙ Общие проблемы Скорость записи на мастере Со стороны MySQL 5
- 10. ∙ Для меня всё могло быть просто ∙ Оригинальная цель исследования ∙ Многие клиенты используют несколько БД ∙ Как правило хорошо знают только одну ∙ Общие проблемы Скорость записи на мастере Максимальная производительность read-only slave Со стороны MySQL 5
- 11. ∙ Для меня всё могло быть просто ∙ Оригинальная цель исследования ∙ Многие клиенты используют несколько БД ∙ Как правило хорошо знают только одну ∙ Общие проблемы Скорость записи на мастере Максимальная производительность read-only slave Checksums, синхронизация, компрессия Со стороны MySQL 5
- 12. ∙ Для меня всё могло быть просто ∙ Оригинальная цель исследования ∙ Многие клиенты используют несколько БД ∙ Как правило хорошо знают только одну ∙ Общие проблемы ∙ Один вопрос: как получить лучшие результаты для каждой из баз на одинаковом оборудовании? Со стороны MySQL 5
- 13. ∙ Для меня всё могло быть просто ∙ Оригинальная цель исследования ∙ Один вопрос: как получить лучшие результаты для каждой из баз на одинаковом оборудовании? ∙ Нужно использовать одинаковые тесты Со стороны MySQL 5
- 14. Трудности, с которыми я столкнулась
- 15. ∙ Машина Percona ∙ Процессоры: physical = 2, cores = 12, virtual = 24, hyperthreading = yes ∙ Память: 251.9G ∙ Скорость диска: about 33K IOPS ∙ Машина Freematiq ∙ Процессоры: physical = 4, cores = 72, virtual = 144, hyperthreading = yes ∙ Память: 3,0T ∙ Скорость диска: about 3K IOPS Неожиданности read-write 7
- 16. ∙ Машина Percona OLTP test statistics: transactions: 1000000 (28727.81 per sec.) read/write requests: 5000000 (143639.05 per sec.) other operations: 2000000 (57455.62 per sec.) ∙ Машина Freematiq transactions: 1000000 (29784.74 per sec.) read/write requests: 5000000 (148923.71 per sec.) other operations: 2000000 (59569.49 per sec.) ∙ Производительность одинаковая ∙ Я бы хотела использовать все ядра! Первые результаты 8
- 17. ∙ Сразу получилось 700 QPS ∙ SysBench использовал столько же CPU, сколько и MySQL PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4585 smirnova 20 0 0,157t 0,041t 9596 S 7226 1,4 12:27.16 mysqld 8745 smirnova 20 0 1266212 629148 1824 S 7126 0,0 9:22.78 sysbench Попытка #2: Read-only 100% в памяти 9
- 18. ∙ Сразу получилось 700 QPS ∙ SysBench использовал столько же CPU, сколько и MySQL ∙ Решение ∙ Запускать sysbench с опциями –percentile=0 –max-requests=0 ∙ Ветка concurrency_kit в SysBench ∙ Переписать *lua скрипты с использованием Prepared Statements Попытка #2: Read-only 100% в памяти 9
- 19. ∙ Сразу получилось 700 QPS ∙ SysBench использовал столько же CPU, сколько и MySQL ∙ Решение ∙ Написать хорошие тесты - это непросто! Попытка #2: Read-only 100% в памяти 9
- 20. Промежуточные результаты и аномалии
- 21. ∙ vm.swappiness=1 ∙ cpupower frequency-set –governor performance ∙ kernel.sched_autogroup_enabled=0 ∙ kernel.sched_migration_cost_ns= 5000000 ∙ vm.dirty_background_bytes=67108864 ∙ vm.dirty_bytes=536870912 ∙ IO scheduler [deadline] Системная конфигурация 11
- 22. ∙ 5.7.15-9 Percona Server (GPL), Release 9 ∙ За основу взята конфигурация Дмитрия ∙ (С небольшими изменениями) RO конфигурация MySQL 12
- 23. ∙ 5.7.15-9 Percona Server (GPL), Release 9 ∙ За основу взята конфигурация Дмитрия ∙ General-Files # general table_open_cache = 8000 table_open_cache_instances=16 back_log=1500 query_cache_type=0 max_connections=4000 # files innodb_file_per_table innodb_log_file_size=1024M innodb_log_files_in_group=3 innodb_open_files=4000 RO конфигурация MySQL 12
- 24. ∙ 5.7.15-9 Percona Server (GPL), Release 9 ∙ За основу взята конфигурация Дмитрия ∙ Мониторинг-Buffers # Monitoring innodb_monitor_enable = ’%’ performance_schema=OFF #cpu-bound, matters for performance #Percona Server specific userstat=0 thread-statistics=0 # buffers innodb_buffer_pool_size= 128000M (32000M) innodb_buffer_pool_instances=128 (32) innodb_log_buffer_size=64M RO конфигурация MySQL 12
- 25. ∙ 5.7.15-9 Percona Server (GPL), Release 9 ∙ За основу взята конфигурация Дмитрия ∙ InnoDB-специфичные # tune innodb_checksums=1 (0) innodb_use_native_aio=1 innodb_doublewrite= 1 innodb_stats_persistent = 1 innodb_support_xa=0 innodb_spin_wait_delay=6 innodb_thread_concurrency=0 join_buffer_size=32K innodb_flush_log_at_trx_commit=2 sort_buffer_size=32K innodb_flush_method=O_DIRECT_NO_FSYNC innodb_max_dirty_pages_pct=90 innodb_max_dirty_pages_pct_lwm=10 innodb_lru_scan_depth=4000 innodb_page_cleaners=4 RO конфигурация MySQL 12
- 26. ∙ 5.7.15-9 Percona Server (GPL), Release 9 ∙ За основу взята конфигурация Дмитрия ∙ Для производительности # perf special innodb_adaptive_flushing = 1 innodb_flush_neighbors = 0 innodb_read_io_threads = 4 innodb_write_io_threads = 4 innodb_io_capacity=2000 innodb_io_capacity_max=4000 innodb_purge_threads=4 innodb_max_purge_lag_delay=30000000 innodb_max_purge_lag=0 innodb_adaptive_hash_index=0 RO конфигурация MySQL 12
- 27. LD_PRELOAD=/data/sveta/5.7.14/lib/mysql/libjemalloc.so /data/sveta/sbkk/bin/sysbench [–test=/data/sveta/sysbench/sysbench/tests/db/oltp_prepared.lua | –test=/data/sveta/sysbench/sysbench/tests/db/oltp_simple_prepared.lua ] –db-driver=mysql –oltp-tables-count=8 –oltp-table-size=10000000 –mysql-table-engine=innodb –mysql-user=msandbox –mysql-password=msandbox –mysql-socket=/tmp/mysql_sandbox5715.sock –num-threads=$i –max-requests=0 –max-time=300 –percentile=0 [–oltp-read-only=on –oltp-skip-trx=on ] run Параметры sysbench 13
- 28. 1 4 16 36 72 144 512 1024 0 200,000 400,000 600,000 800,000 1,000,000 Threads Запросы/s Результаты Дмитрия SysBench OLTP RO Результаты RO хуже, чем у Дмитрия 14
- 29. 1 4 16 36 72 144 512 1024 0 500,000 1,000,000 1,500,000 2,000,000 Threads Запросы/s РезультатыДмитрия PointSELECT Результаты RO хуже, чем у Дмитрия 15
- 30. ∙ Open files - Monitoring #Open files table_open_cache = 8000 table_open_cache_instances = 16 query_cache_type = 0 join_buffer_size=32k sort_buffer_size=32k max_connections=16000 back_log=5000 innodb_open_files=4000 #Monitoring performance-schema=0 #Percona Server specific userstat=0 thread-statistics=0 RW конфигурация MySQL 16
- 31. ∙ InnoDB general и concurrency #General innodb_buffer_pool_load_at_startup=1 innodb_buffer_pool_dump_at_shutdown=1 innodb_numa_interleave=1 innodb_file_per_table=1 innodb_file_format=barracuda innodb_flush_method=O_DIRECT_NO_FSYNC innodb_doublewrite=1 innodb_support_xa=1 innodb_checksums=1 #Concurrency innodb_thread_concurrency=144 innodb_page_cleaners=8 innodb_purge_threads=4 #with 1 seem to be more stable innodb_spin_wait_delay=12 #Good value for RO is 6, for RW and RC is 192 RW конфигурация MySQL 16
- 32. ∙ InnoDB buffer, log и IO capacity innodb_log_file_size=8G innodb_log_files_in_group=16 innodb_buffer_pool_size=128G innodb_buffer_pool_instances=128 innodb_io_capacity=18000 innodb_io_capacity_max=36000 innodb_flush_log_at_timeout=0 innodb_flush_log_at_trx_commit=2 RW конфигурация MySQL 16
- 33. ∙ InnoDB performance, load specific innodb_flush_sync=1 innodb_adaptive_flushing=1 innodb_flush_neighbors = 0 innodb_max_dirty_pages_pct=90 innodb_max_dirty_pages_pct_lwm=10 innodb_lru_scan_depth=4000 innodb_adaptive_hash_index=0 innodb_change_buffering=none #can be inserts optimizer_switch="index_condition_pushdown=off" RW конфигурация MySQL 16
- 34. 1 4 16 36 72 144 512 1024 0 10,000 20,000 30,000 40,000 50,000 Threads Transactions/s REPEATABLE READ READ COMMITTED Аномалия READ COMMITTED 17
- 35. 1 4 16 36 72 144 512 1024 0 5,000 10,000 15,000 Threads Transactions/s REPEATABLE READ READ COMMITTED RR vs RC на 24 ядрах 18
- 36. 1 4 16 36 72 144 512 1024 0 10,000 20,000 30,000 40,000 50,000 Threads Transactions/s HD Ramdisk Аномалия IO 19
- 38. 1 4 16 36 72 144 512 1024 0 10,000 20,000 30,000 40,000 50,000 Threads Transactions/s 2 1 innodb_flush_log_at_trx_commit 1 vs 2 21
- 39. 1 4 16 36 72 144 512 1024 0 10,000 20,000 30,000 40,000 50,000 Threads Transactions/s 1 0 innodb_doublewrite 1 vs 0 22
- 40. 1 4 16 36 72 144 512 1024 0 10,000 20,000 30,000 40,000 50,000 Threads Transactions/s 1 0 innodb_checksums 1 vs 0 23
- 41. 1 4 16 36 72 144 512 1024 0 10,000 20,000 30,000 40,000 50,000 Threads Transactions/s BinarylogOFF sync_binlog = 1 sync_binlog = 0 sync_binlog 1 vs 0 24
- 42. MySQL: почему эти результаты стали возможны
- 43. ∙ InnoDB: оптимизация transaction list Ключевые изменения 26
- 44. ∙ InnoDB: оптимизация transaction list ∙ Версия 5.7.2: глобальный transaction был разбит на два Read-write Read-only Ключевые изменения 26
- 45. ∙ InnoDB: оптимизация transaction list ∙ Версия 5.7.2: глобальный transaction был разбит на два Read-write Read-only ∙ Версия 5.7.3: по умолчанию транзакция независима, если только не была открыта с опцией READ WRITE Read only транзакции mutex-free READ ONLY транзакций нет в выводе SHOW ENGINE INNODB STATUS Ключевые изменения 26
- 46. ∙ InnoDB: оптимизация transaction list ∙ Версия 5.7.2: глобальный transaction был разбит на два Read-write Read-only ∙ Версия 5.7.3: по умолчанию транзакция независима, если только не была открыта с опцией READ WRITE Read only транзакции mutex-free READ ONLY транзакций нет в выводе SHOW ENGINE INNODB STATUS ∙ Подробнее ∙ WL #6047 Ключевые изменения 26
- 47. ∙ InnoDB: оптимизация transaction list ∙ InnoDB: уменьшен lock_sys_t::mutex contention, WL #6899 Ключевые изменения 26
- 48. ∙ InnoDB: оптимизация transaction list ∙ InnoDB: уменьшен lock_sys_t::mutex contention, WL #6899 ∙ InnoDB: исправлен index->lock contention WL #6326 Ключевые изменения 26
- 49. ∙ InnoDB: быстрый и параллельный flushing Ключевые изменения 26
- 50. ∙ InnoDB: быстрый и параллельный flushing ∙ Несколько потоков page cleaner: WL #6642 Ключевые изменения 26
- 51. ∙ InnoDB: быстрый и параллельный flushing ∙ Несколько потоков page cleaner: WL #6642 ∙ Улучшен адаптивный flushing: WL #7868 Ключевые изменения 26
- 52. ∙ InnoDB: быстрый и параллельный flushing ∙ Несколько потоков page cleaner: WL #6642 ∙ Улучшен адаптивный flushing: WL #7868 ∙ Уменьшено число страниц, которое должно быть flushed: WL #7047 Ключевые изменения 26
- 53. ∙ Масштабируемость MDL (Meta-Data Lock) Ключевые изменения 26
- 54. ∙ Масштабируемость MDL (Meta-Data Lock) ∙ Убран THR_LOCK::mutex для InnoDB: WL #6671 Ключевые изменения 26
- 55. ∙ Масштабируемость MDL (Meta-Data Lock) ∙ Убран THR_LOCK::mutex для InnoDB: WL #6671 ∙ Разбит на части LOCK_grant Количество постоянное Thread ID используется для выбора партиции WL #8355 Bug #72829 Ключевые изменения 26
- 56. ∙ Масштабируемость MDL (Meta-Data Lock) ∙ Убран THR_LOCK::mutex для InnoDB: WL #6671 ∙ Разбит на части LOCK_grant ∙ Lock-free MDL lock acquisition для DML: WL #7306, WL #7305 Ключевые изменения 26
- 57. ∙ Performance Schema быстрее, чем раньше ∙ Я заметила влияние не на всех тестах ∙ Я НЕ включала никаких инструментов Другие улучшения производительности MySQL 27
- 58. ∙ Performance Schema быстрее, чем раньше ∙ Быстрый innodb_checksum_algorithm crc32 по умолчанию Другие улучшения производительности MySQL 27
- 59. ∙ Performance Schema быстрее, чем раньше ∙ Быстрый innodb_checksum_algorithm crc32 по умолчанию ∙ Производительность InnoDB Temporary Table ∙ Нет UNDO и REDO logging ∙ Нет Insert buffering ∙ Нет persistence ∙ WL #6469, WL #6470, WL #6915, https://goo.gl/LeIYD4 Другие улучшения производительности MySQL 27
- 60. ∙ Performance Schema быстрее, чем раньше ∙ Быстрый innodb_checksum_algorithm crc32 по умолчанию ∙ Производительность InnoDB Temporary Table ∙ Выгрузка и загрузка InnoDB buffer pool Другие улучшения производительности MySQL 27
- 61. ∙ Performance Schema быстрее, чем раньше ∙ Быстрый innodb_checksum_algorithm crc32 по умолчанию ∙ Производительность InnoDB Temporary Table ∙ Выгрузка и загрузка InnoDB buffer pool ∙ И много чего ещё Другие улучшения производительности MySQL 27
- 62. PostgreSQL
- 63. Трудности
- 64. ∙ Проблема: обработка NULL для PostgreSQL сломана в sysbench. [fontsize=] FATAL: failed to execute function ‘event’: 3 (last message repeated 7 times) FATAL: PQexecPrepared() failed: 7 ERROR: invalid input syntax for integer: ∙ Починено. Алексей Копытов смёржил pull request. [fontsize=] /* Convert SysBench bind structures to PgSQL data */ for (i = 0; i < (unsigned)pgstmt->nparams; i++) { - if (stmt->bound_param[i].is_null) + if (stmt->bound_param[i].is_null && *(stmt->bound_param[i].is_null)) continue; switch (stmt->bound_param[i].type) { sysbench и prepared statements: попытка 1 30
- 65. ∙ Проблема 2: sysbench не может нагрузить PostgreSQL, когда используются prepared statements. [fontsize=] 93087 korotkov 20 0 9289440 3,718g 2964 S 242,6 0,1 0:32.82 sysbench 93161 korotkov 20 0 32,904g 81612 80208 S 4,0 0,0 0:00.47 postgres 93116 korotkov 20 0 32,904g 80828 79424 S 3,6 0,0 0:00.46 postgres 93118 korotkov 20 0 32,904g 80424 79020 S 3,6 0,0 0:00.47 postgres 93121 korotkov 20 0 32,904g 80720 79312 S 3,6 0,0 0:00.47 postgres 93128 korotkov 20 0 32,904g 77936 76536 S 3,6 0,0 0:00.46 postgres 93130 korotkov 20 0 32,904g 81604 80204 S 3,6 0,0 0:00.47 postgres 93146 korotkov 20 0 32,904g 81112 79704 S 3,6 0,0 0:00.46 postgres .............................................................................. ∙ ...решено пока забить на sysbench и пользоваться pgbench! sysbench и prepared statements: попытка 2 31
- 66. set table_size 10000000 set range_size 100 set id1 random(1, :table_size) ............................................................... set id10 random(1, :table_size) set r1l random(1, :table_size) set r1u :r1l + :range_size ............................................................... set r4l random(1, :table_size) set r4u :r4l + :range_size SELECT c FROM sbtest WHERE id = :id1; ............................................................... SELECT c FROM sbtest WHERE id = :id10; SELECT c FROM sbtest WHERE id BETWEEN :r1l AND :r1u; SELECT SUM(K) FROM sbtest WHERE id BETWEEN :r2l AND :r2u; SELECT c FROM sbtest WHERE id BETWEEN :r3l AND :r3u ORDER BY c; SELECT DISTINCT c FROM sbtest WHERE id BETWEEN :r4l AND :r4u; OLTP RO скрипт для pgbench 32
- 67. set table_size 10000000 ............................................................... set u1 random(1, :table_size) set u2 random(1, :table_size) set u3 random(1, :table_size) set u4 random(1, :table_size) BEGIN; SELECT c FROM sbtest WHERE id = :id1; ............................................................... SELECT DISTINCT c FROM sbtest WHERE id BETWEEN :r4l AND :r4u; UPDATE sbtest SET k = k + 1 WHERE id = :u1; UPDATE sbtest SET c = sb_rand_str(’###########-###########-###########-###########-###########-######## DELETE FROM sbtest WHERE id = :u3; INSERT INTO sbtest (id, k, c, pad) VALUES (:u3, :u4, sb_rand_str(’###########-###########-###########-# COMMIT; Пришлось реализовать sb_rand_str() на стороне PostgreSQL на C. OLTP RW скрипт для pgbench 33
- 68. Всё на github’е и воспроизводится! [fontsize=] $ git clone https://github.com/postgrespro/pg_oltp_bench.git $ cd pg_oltp_bench $ make USE_PGXS=1 $ sudo make USE_PGXS=1 install $ psql DB -f oltp_init.sql $ psql DB -c "CREATE EXTENSION pg_oltp_bench;" $ pgbench -c 100 -j 100 -M prepared -f oltp_ro.sql -T 300 -P 1 DB $ pgbench -c 100 -j 100 -M prepared -f oltp_rw.sql -T 300 -P 1 DB Как его запускать? 34
- 69. Результаты
- 73. Результаты: OLTP RW ramdisk 39
- 74. Результаты: OLTP RW checksums 40
- 75. Как это стало возможно
- 76. Перед тем как “потрогать” любой блок данных, backend вначале должен “запинить” соответствующий буфер. Pin/UnpinBuffer – очень частая операция. Было: S_LOCK(bufHdr); bufHdr->pinCount++; S_UNLOCK(bufHdr); Стало: atomic_increment(buf_hdr->pinCount); См. commit: https://goo.gl/LLCvR8. Pin/UnpinBuffer in lockless manner 42
- 77. ∙ Снапшот содержит список id запущенных транзакций. Для получения снапшота нужно взять shared ProcArrayLock. ∙ Commit транзакции очищает её id из разделяемой памяти. Для commit’а транзакции нужен exclusive ProcArrayLock. ∙ Высокий TPS приводит к высокой конкуренции за ProcArrayLock. ∙ Решение: очищать id транзакций пачками. См. commit: https://goo.gl/ZxiilI. Уменьшение конкуренции за ProcArrayLock 43
- 78. ∙ Получение статуса транзакции требует shared CLogControlLock. Установка статуса транзакции требует exclusive CLogControlLock. Чтение станицы CLOG требует exclusive CLogControlLock. ∙ На современных многоядерных архитектурах, backend’ы часто получают статусы транзакций. Число запрашиваемых транзакций также высоко. ∙ Решение: увеличить число буферов CLOG с 32 до 128. Благодаря этого страницы CLOG нужно будет реже читать. See commit details: https://goo.gl/aaPYsJ. Уменьшение конкуренции за CLogControlLock 44
- 79. Перспективы
- 80. Где бутылочное горлышко у PostgreSQL? 46
- 81. Где бутылочные горлышки у PostgreSQL? 47
- 82. ∙ Buffer manager – медленная хэш таблица, “пин”, блокировки. ∙ Снэпшоты – для получения каждого снэпшота нужно просканировать все активные транзакции. ∙ Синхронный протокол. ∙ Медленное выделение id транзакции – много блокировок. Где бутылочные горлышки у PostgreSQL? 48
- 83. ∙ SELECT val FROM tab WHERE id IN (:id1, ... :id10) – 150K в секунду = 1.5M точечных запросов в секунду, нет выигрыша. Упираемся в buffer manager. ∙ 10 x SELECT 1 в одну команду – 2.2M запросов в секунду. Упираемся во взятие снэпшота. ∙ SELECT 1 с CSN патчем (дешёвые снэпшоты) – 3.9M запросов в секунду. Упираемся в протокол. ∙ SELECT txid_current() – 390K запросов в секунду. Упираемся в блокировки. Бутылочные горлышки PostgreSQL в цифрах 49
- 84. ∙ In-memory табличный движок без buffer manager’а. ∙ CSN для быстрого взятие снапшотов. ∙ Асинхронный бинарный протокол позволит обработать больше коротких запросов. ∙ Lockless выделение id транзакций. Как улучшить PostgreSQL? 50
- 85. Сравнение
- 91. Итоги
- 92. ∙ MySQL и PostgreSQL – динамично развивающиеся open source СУБД, быстро адаптирующиеся под современной железо. ∙ Релизы MySQL 5.7 и PostgreSQL 9.6 содержат серьёзные улучшения вертикальной масштабируемости (consider upgrade). Итоги 58
- 93. ∙ Freematiq за предоставленные сервера ∙ MySQL Server Team ∙ MySQL InnoDB Team ∙ Dimitri Kravtchuk ∙ Alexey Kopytov Благодарности 59
- 94. ∙ sysbench ∙ pgbench ∙ pg_oltp_bench ∙ open-database-bench Использованные инструменты 60
- 95. у нас есть ответов. У вас есть вопросов, 61