Scaling PostgreSQL
5 likes1,125 views
Документ описывает достижения PostgreSQL на платформе IBM Power 8, включая записанные рекорды производительности и масштабируемости. Основное внимание уделяется основным свойствам PostgreSQL, таким как надежность, расширяемость и устойчивость при высокой нагрузке, а также вкладу российских разработчиков в его развитие. Также упоминаются планы по дальнейшему улучшению производительности, включая оптимизацию менеджера буферов и алгоритма изоляции транзакций.
![12
Чем занят CPU
perf top
33.48% postgres [.] s_lock
2.51% postgres [.] GetSnapshotData
1.82% postgres [.] PinBuffer](https://image.slidesharecdn.com/scalingpostgresql-150917181807-lva1-app6891/85/Scaling-PostgreSQL-12-320.jpg)
![18
Чем занят CPU после оптимизаций
Стало:
perf top
13.75% postgres [.] GetSnapshotData
4.88% postgres [.] AllocSetAlloc
2.47% postgres [.] LWLockAcquire
Было:
perf top
33.48% postgres [.] s_lock
2.51% postgres [.] GetSnapshotData
1.82% postgres [.] PinBuffer](https://image.slidesharecdn.com/scalingpostgresql-150917181807-lva1-app6891/85/Scaling-PostgreSQL-18-320.jpg)
Scaling PostgreSQL
- 1. Новый рекорд производительности и масштабируемости PostgreSQL на IBM POWER 8
- 2. 2 Что такое PostgreSQL PostgreSQL – это свободно распространяемая объектно- реляционная СУБД (ORDBMS) Поддержка ANSI SQL (1992...2011), а также NoSQL (key-value, JSON, JSONB) Web: http://www.postgresql.org Лицензия: BSD, MIT-like
- 4. 4 Важнейшие свойства Надежность и устойчивость PostgreSQL Надежность PostgreSQL является известным и доказанным фактом на примере многих проектов, в которых PostgreSQL работает без единого сбоя и при больших нагрузках на протяжении нескольких лет. Кроссплатформенность PostgreSQL поддерживает все виды Unix, включая Linux, FreeBSD, Solaris, HPUX, Mac OS X, а также MS Windows. Конкурентная работа при большой нагрузке PostgreSQL использует многоверсионность (MVCC) для обеспечения надежной и быстрой работы в конкурентных условиях под большой нагрузкой. Масштабируемость PostgreSQL отлично использует современную архитектуру многоядерных процессоров. Кластерные решения на базе Postgres XL обеспечивают горизонтальную масштабируемость. Расширяемость Расширяемость PostgreSQL позволяет добавлять новую функциональность, в том числе и новые типы данных, без остановки сервера и своими силами. Доступность PostgreSQL распространяется под лицензией BSD, которая не накладывает никаких ограничений на коммерческое использование и не требует лицензионных выплат. Вы можете даже продавать PostgreSQL под своим именем ! Независимость PostgreSQL не принадлежит ни одной компании, он развивается международным сообществом, в том числе и российскими разработчиками. Независимость PostgreSQL означает независимость вашего бизнеса от вендора и сохранность инвестиций. Превосходная поддержка Сообщество PostgreSQL предоставляет квалифицированную и быструю помощь. Коммерческие компании предлагают свои услуги по всему миру.
- 5. 5 Российские разработчики Олег Бартунов, Федор Сигаев, Александр Коротков Внесли вклад в PostgreSQL: ● Поддержка локализации ● Полнотектовый поиск ● Слабоструктурированные данные ● Новые методы индексации ● Различные расширения
- 6. 6 Postgres Professional ● Российский вендор PostgreSQL в России ● Поддержка, разработка, консалтинг, обучение ● Тему технологической независимости СУБД пропагандируем с 2011 г. ● Члены международного сообщества ● Спонсоры международных конференций (Канада, Австрия, Бразилия) ● PgConf.Russia - крупнейшая в мире конференция по PostgreSQL ● В направлениях, где мы ведем разработку, PostgreSQL является лидером* среди РСУБД ● геоинформационные системы, слабоструктурированные данные, полнотекстовый поиск, расширяемость ● Более 20 докладов на международных конференциях ● Все российские ключевые международно признанные разработчики PostgreSQL работают в нашей компании ● В нашей команде 4 кандидата наук: 3 – по PostgreSQL и технологиям БД
- 7. 7 Postgres Professional МАСШТАБИРУЕМОСТЬ * * Это способность увеличивать свою производительность при добавлении ресурсов
- 8. 8 Архитектура с точки зрения ОС Storage Shared Buffers Backend Backend Backend BgWorkers
- 12. 12 Чем занят CPU perf top 33.48% postgres [.] s_lock 2.51% postgres [.] GetSnapshotData 1.82% postgres [.] PinBuffer
- 13. 13 Кто сказал мяу? gdb #0 0x00003fffac40a858 in ___newselect_nocancel () from /lib64/power8/libc.so.6 #1 0x00000000106105f0 in pg_usleep (microsec=<optimized out>) at pgsleep.c:53 #2 0x00000000103e5f18 in s_lock (lock=0x3fe607980be0, file=0x10718398 "bufmgr.c", line=<optimized out>) at s_lock.c:110 #3 0x00000000103aea10 in UnpinBuffer (buf=0x3fe607980bc0, fixOwner=1 '001') at bufmgr.c:1540 #4 0x00000000103b4910 in ReleaseAndReadBuffer (buffer=<optimized out>, relation=0x3fe6067073e0, blockNum=<optimized out>) at bufmgr.c:1401
- 14. 14 Что мы заметили (1.82% в perf)
- 15. 15 PostgreSQL Instance Еще один взгляд на архитектуру Shared Buffers Backend BgWorkerspage №X Backend Backend Client Client Client page №1 page №2 page №3 page ...
- 16. 16 Изоляция критического участка * Semaphores + Простота реализации (Posix) - Низкая эффективность * Атомарные операции (Fetch And Add, ...) + Эффективная поддержка со стороны компиляторов (gcc/clang, xlc, msvc) - Изоляция одного значения, более сложные алгоритмы * Spin lock + Полный контроль алгоритма - Эффективна изоляция только небольшого куска кода.
- 17. 17 s_lock основан на spin lock
- 18. 18 Чем занят CPU после оптимизаций Стало: perf top 13.75% postgres [.] GetSnapshotData 4.88% postgres [.] AllocSetAlloc 2.47% postgres [.] LWLockAcquire Было: perf top 33.48% postgres [.] s_lock 2.51% postgres [.] GetSnapshotData 1.82% postgres [.] PinBuffer
- 21. 21 Что все это значит PostgreSQL работает внутри LPAR * При помощи Power Hypervisor можно легко масштабировать PostgreSQL** * Данные синтетические тесты не означают что Stable PostgreSQL 9.4 будет в общем случае работать хуже при cpu > 120 ** Внимание! Это не реклама!
- 22. 22 Что все это значит Эффективная утилизация ресурсов
- 23. 23 Что все это значит Количество одновременно работающих клиентов
- 24. 24 Планы Сделать новый Buffer Manager* * оценочно речь идет об увеличении производительности до 2 раз (!!!)
- 25. 25 Планы Улучшение алгоритма изоляции транзакций* * оценочно до +10% производительности
- 26. 26 Планы Оптимизация Buffer Manager для NUMA-архитектуры * ** * оценочно до +10-15% производительности ** очень тяжелая задача
- 27. 27 Обещанный рекорд 1,8 миллиона транзакций в секунду на одном IBM Power 8 / 64 Core процессоров * ** * цель теста — не получение астрономического значения попугаев, а выяснение узких мест для оптимизаций ** достигнуто на двух инстансах PostgreSQL, одновременно запущеных на большом LPAR.
- 28. 28 Спасибо за внимание! Дмитрий Васильев Postgres Professional http://www.postgrespro.ru/ [email protected]
- 31. 31 База данных ”X” Её под Linux PPC не достать :)
Editor's Notes
- #3: PostgreSQL - наиболее полнофункциональная, свободно распространяемая СУБД с открытым кодом. Разработанная в академической среде, за долгую историю сплотившая вокруг себя широкое сообщество разработчиков, эта СУБД обладает всеми возможностями, необходимыми большинству заказчиков. PostgreSQL активно применяется по всему миру для создания критичных бизнес-систем, работающих под большой нагрузкой.
- #4: PostgreSQL имеет широкую клиентскую базу. Среди крупнейших пользователей PostgreSQL можно отметить: Skype (сейчас Microsoft), Yahoo, Instagram, BASF, Afilias и другие. PostgreSQL получил широкое распространение и в России. Вот лишь некоторые из российских компаний, где активно используется PostgreSQL: Rambler, Yandex, Avito, Headhunter.
- #6: Вклад российских разработчиков в PostgreSQL весьма значительный. Это один из самых крупных глобальных open source проектов, с таким широким российским представительством. Огромную роль в становлении и развитии PostgreSQL сыграл, входивший в Управляющий комитет, Вадим Михеев (сейчас отошел от проекта). Он является автором таких важнейших частей системы как: многоверсионное управление одновременным доступом (MVCC), система очистки (Vacuum), журнал транзакций (WAL), вложенные запросы, триггеры. Олег Бартунов, Федор Сигаев и Александр Коротков внесли вклад в PostgreSQL, такой как: Поддержка локализации, полнотекстовый поиск, слабоструктуированые данные (jsonb, hstore), новые методы индексации и различные расширения, в том числе например необходимые для работы 1С
- #7: Все указаные люди работают в компании Postgres Professional. Компания “Постгрес Профессиональный”, одной из своих важных задач ставит существенное увеличение российского представительства в глобальной группе разработчиков PostgreSQL.
- #8: Мой доклад посвящен масштабируемости PostgreSQL.
- #9: На данной схеме очень представлена упрощенная архитектура PostgreSQL. PostgreSQL делает форк на каждый новый коннект к базе, так что отдельный клиент – это отдельный процесс в системе, который может общаться как со стораджем, так и с общей разделяемой памятью между процессами backend&apos;a. Задача масштабирования по CPU, это задача увеличение перфоманса при увеличении хардварно-независимых CPU. Способность эффективно утилизировать современную многоядерную архитектуру, является одной из важных направлений для развития PostgreSQL.
- #10: Задача масштабирование по CPU начали проводиться давно. Самые известные измерения провел Robert Haas, сотрудник компании EnterpriseDB, которая занимается разработкой и поддержкой паралельного форка PostgreSQL. В 2011 году: PG 9.1 линейной масштабировался до 16 клиентов. На графике представлены измерения 2012 года, PG версии 9.2, его результат 64 клиента Это была успешная попытка оптимизации модели локов в PostgreSQL для многоядерной архитектуры.
- #11: Благодоря Российскому отделению IBM мы получили доступ к IBM 9119-MHE, который состоит из 8 сокетов по 8 ядер процессоров. Мы провели аналогичные тесты, они показали, что с момента релиза 9.2 PostgreSQL продолжает увеличивает свою производительность на многоядерной архитектуре. Альфа версия PostgreSQL 9.5 за счет оптимизаций алгоритма локов смогла увеличить производительности по сравнению с текущим стабильным релизом 9.4 почти в 1.5 раза.
- #12: Возвращаясь к определению масштабирования, мы построили график по оси X отложено количество ядер, которое выделено для PostgreSQL, а по оси Y максимальное количество произведеных транзакций в секунду. Видно, что насышение происходит на 60 ядрах у 9.4 и 150 ядрах у 9.5
- #13: Соответственно возникает вопрос, чем занимаеться CPU. Выбор пал на станадартную утилиту perf. Perf – это профилировщик linux, который имеет поддержку со стороны ядра. Функция профилировщика - найти узкие места в программе и выдать нам как можно больше информации о том куда уходят процессорные такты. Perf занимаеться статистическим профилированием: на этапе исполнения программы периодически (~100-1000 раз в секунду) программа останавливается и управление передается профилировщику, который анализирует текущий констекст исполнения. Затем, используя отладочную информацию или таблицу символов из исполняемого файла программы и загруженных библиотек, определяется исполняемая в текущий момент функция и, если возможно, последовательность вызовов в стеке. Как видно из вывода perf, большее количество времени postgres проводит в функции s_lock.
- #14: Как я сказал, в задачи профилировщика также входит задача построения последовательности вызовов в стеке. Оказалось, что на таких скоростях невозможно было его использовать в контексте построения дерева вызова. 10 секундный самплинг строился порядка нескольких часов. Поэтому пришлось использовать кастомное решение, брать random probe на основе gdb. Что позволило разобраться, кто вызывает функцию s_lock
- #15: Если вы смогли разглядеть предыдущий слайд, то увидели бы там что речь шла о функциях Pin/UnPinBuffer
- #16: Давайте попробуем заглянуть чуть-чуть поглубже в архитектуру PostgreSQL. Ее можно представить так. Видно, что чем больше количество одновременно работающих клиентов, тем выше вероятность возникновения конкуренции за опеределенную страницу общей разделяемой памяти между бакэндами. GDB нам подсказал, что s_lock - это конкуренция банкендов за конкретные страницы. Что в принципе согласуется с этим представлением. Для чего же вызвается s_lock?
- #17: s_lock – это изоляция критической секции, тн BottleNeck. Участок исполняемого кода программы, в котором производится доступ к общему ресурсу (в нашем случае это данные), которые не могут быть одновременно использованы более чем одним запущеным процессом. масштабирование PostgreSQL зависит от реализации алгоритмов конкурентного доступа На данный момент у PostgreSQL несколько реализации алгоритмов конкурентного доступа. 1. Семафоры: Семафо́р — объект, ограничивающий количество потоков, которые могут войти в заданный участок кода. Основной его плюс это простота реализация входит в Posix. Основная проблема – это низкая эффективность. 2. Атомарные операции построены на инструкциях процессора, которые могут заблокировать и обновить данные. 3. SPIN LOCK основан на атомарных операциях, он предварительно проверяет переменную-флажок и в случае необходимости переводит процесс в sleep.
- #19: Найдя узкое место, разбив задачу на несколько частей, проведя работу над BufferManager мы заменили кусок кода с s_lock на атомарные операции что нам позволило достичь увеличения производительности.
- #20: На графике представлено сравнение PG 9.5 vanila vs PG 9.5 atomic patch Как мы видим производительность выросла почти до 900тыс транзакций в секунду. И масштабируеться почти до 350 клиентов.
- #21: Соотвественно выросло масштабирование! Как видно из графика PostgreSQL в данном use-case начал масштабироваться до 250 CPU И позволил утилизировать половину предоставленных ядер IBM Power 8 64 Cores
- #22: Какие выводы можно сделать из этого? Ну во первых, мы поняли что PostgreSQL работает внутри LPAR. Масштабированием LPAR можно масштабировать PostgreSQL на чтение.
- #23: C PostrgreSQL вы можете быть увереным что ваши данные не только надежно сохранны, но и также, что ваше драгоценное железо эффективно утилизировано. Ваша база будет делать клиентов счастливыми, нежели заниматься сугубо внутренней работой.
- #24: С точки зрения бизнеса это означает что с PostgreSQL может работать большее количество одновременно работающих клиентов.
- #25: Данный патч предоставляет из себя только заготовку для дальнейшей оптимизации Buffer Manager&apos;а. В планах нашей компании переделать Buffer Manager с учетом работы в условиях многопроцессорной архитектуры и внести изменения в последующие релизы PostgreSQL 9.6
- #26: По данным наших тестов, улучшения алгортима изоляции транзакции может увеличить перформанс до 10%
- #27: Мы конечно же не могли не провести измерения влияния NUMA-архитектуры. Измерения показали, что мы можем получить 10-15% деградации, если данные с которыми работает бакэнд находится на самой удаленной numa-ноде.
- #28: Ну и соответственно обещаный рекорд :)
- #29: Спасибо!
- #30: Спасибо!