Серия «СУБД PostgreSQL»

Оценка производительности PostgreSQL - одного сценария НЕДОСТАТОЧНО

Взято с основного технического канала Postgres DBA

Оценка производительности PostgreSQL - одного сценария НЕДОСТАТОЧНО Postgresql, Субд, Мониторинг, Производительность, Тестирование, Тест, Длиннопост

До финиша дойдут не все...

Проблема

ВМ с гораздо большими вычислительными ресурсами показывает скорость ниже , чем более скромная ВМ .

Причина

По умолчанию pgbench тестирует сценарий, примерно соответствующий TPC-B, который состоит из пяти команд SELECT, UPDATE и INSERT в одной транзакции.

Postgres Pro Enterprise : Документация: 16: pgbench : Компания Postgres Professional

Для тестирования использовался именно этот сценарий .

Конфигурация виртуальных машин

ВМ-1

Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Soft 11.4.0-1), 64-bit

CPU = 8

RAM = 15

OC = RED 7.3

ВМ-2

Postgres Pro (enterprise certified) 14.11.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit

CPU = 24

RAM = 189

ОС = Astra Linux (Smolensk) 1.6

Итоги теста по сценарию TPC-B

Оценка производительности PostgreSQL - одного сценария НЕДОСТАТОЧНО Postgresql, Субд, Мониторинг, Производительность, Тестирование, Тест, Длиннопост

Производительность ВМ-1 существенно выше ВМ-2

Т.е. по итогам данного теста получается - СУБД развёрнутая по шаблону ВМ-1 будет существенно производительнее ?

Что будет , если архитектор примет решение о выборе версии СУБД и запланирует ресурсы инфраструктуры на основании только данного теста ?

Решение проблемы

Одного теста для анализа производительности СУБД и ВМ - недостаточно.

Как было указано в документации:

Однако вы можете легко протестировать и другие сценарии, написав собственные скрипты транзакций.

Что и было сделано.

Для продолжения тестов, был подготовлен сценарий требующий серьезных вычислительных ресурсов - SELECT ... JOIN

Результат тестирования тяжелого запроса

Оценка производительности PostgreSQL - одного сценария НЕДОСТАТОЧНО Postgresql, Субд, Мониторинг, Производительность, Тестирование, Тест, Длиннопост

ВМ-2 СУЩЕСТВЕННО производительнее чем ВМ-1

Все встало на свои места.

ВМ-1 даже не хватило ресурсов при количестве одновременных запросов свыше 160. При этом производительности ВМ-2 существенно выше производительности ВМ-1.

Итог

  1. Нельзя принимать архитектурных решений на основании результатов одного только сценария нагрузочного тестирования

2. Для оценки производительности архитектурного решения по конкретной СУБД необходим комплекс разных сценариев нагрузочного тестирования.

Как минимум:

-Select only: оценка скорости чтения данных из СУБД

-Standard: оценка производительности СУБД в условиях конкуренции за блокировки.

-Heavyweight: оценка производительности СУБД при выполнении тяжелых вычислительных и ресурсоемких операций.

Показать полностью 2

CPU Utilization = 100%. Это проблема СУБД?

Взято с основного технического канала Postgres DBA

Продолжение материала CPU Utilization = 100%. Это проблема СУБД?

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Мониторинг, Производительность

Ресурс должен работать !

Просто цифры полученные по ходу стресс тестирования СУБД

ВМ-1

CPU Utilization

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Мониторинг, Производительность

ВМ-1 : Максимальная утилизация CPU = 99% . Средняя = 81%

Commited transactions

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Мониторинг, Производительность

ВМ-1 : Максимальное значение 18 550 . Среднее значение = 12 810

ВМ-2

CPU Utilization

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Мониторинг, Производительность

ВМ-2 : Максимальная утилизация CPU = 28%. Средняя = 14%

Commited transactions

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Мониторинг, Производительность

ВМ-2 : Максимальное значение = 4 470 . Среднее значение = 3 320

Итог

При данной нагрузке и данном сценарии тестирования - мониторить утилизацию CPU не имеет никакого смысла.

ВМ-1 утилизация близка к предельной, но при этом количество зафиксированных транзакций в среднем в 4 раза выше.

Что подтверждает ранее сделанные выводы

Выводы

Мониторить утилизацию CPU отдельно — не имеет смысла. Мониторить надо производительность СУБД, в первую очередь.

Рост утилизации CPU — не инцидент. Снижение производительности СУБД и рост утилизации CPU — инцидент.

Высокая утилизация CPU и рост производительности СУБД — показывает эффективное использование предоставленных ресурсов. Низкая утилизация CPU и низкая производительность СУБД в рабочее время — зря потраченные средства.

Показать полностью 4
1

CPU Utilization = 100%. Это проблема СУБД?

Взято с основного технического канала Postgres DBA

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Утилизация CPU = 100%

Обычные последствия после получения оповещения мониторинга «CPU Utilization High» — все в панике, лихорадочные поиски причин, аварийная ситуация, конфколлы и т. д. и т. п. Всё, как положено для ИБД.

Однако, если посмотреть на ситуацию чуть подробнее, то выясняется, что всё не так печально, а даже совсем наоборот и причин для паники — никаких.

Что же происходит с СУБД в данный момент ?

А с СУБД, всё хорошо, достаточно посмотреть на метрики мониторинга.

Самое главное: производительность СУБД — не снижается

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Производительность СУБД даже растёт

Уже этой информации достаточно, что бы прекратить панику и не тратить рабочее время на поиски черной кошки в темной комнате.

Почему, производительность СУБД не снижается, ведь CPU в полку?

Причина 1: Количество запросов в секунду — не снижается

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Количество запросов в секунду не снижается с ростом утилизации СУБД

Причина 2: Количество транзакций в секунду — не снижается

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Количество транзакций в секунду - не снижается с ростом утилизации CPU

Т.е. можно сделать простой вывод‑ работоспособность СУБД не уменьшилась, а скорее наоборот — увеличилась и рост утилизации CPU это лишь следствие. Или другими словами — в данной, конкретной ситуации СУБД максимально эффективно использует предоставленные ресурсы.

Данный тезис подтверждается метриками, показывающими количество обрабатываемой СУБД информации за единицу времени (что собственно говоря, с известными сейчас допущениями, и определяет в некотором смысле производительность СУБД).

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Количество страниц разделяемой области - прочитанных в секунду

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Количество страниц разделяемой области - записанных в секунду

CPU Utilization = 100%. Это проблема СУБД? Postgresql, Субд, Производительность, Мониторинг, Длиннопост

Количество страниц разделяемой области - измененных в секунду

Выводы

  1. Мониторить утилизацию CPU отдельно — не имеет смысла. Мониторить надо производительность СУБД, в первую очередь.

  2. Рост утилизации CPU — не инцидент. Снижение производительности СУБД и рост утилизации CPU — инцидент.

  3. Высокая утилизация CPU и рост производительности СУБД — показывает эффективное использование предоставленных ресурсов. Низкая утилизация CPU и низкая производительность СУБД в рабочее время — зря потраченные средства.

Показать полностью 7

Первый пост

Взято с основного технического канала Postgres DBA

Скоро год , как впервые возникла мысль - "надо рассчитывать производительность СУБД".

Столько прошло с тех пор - несколько вариантов расчета , решение аномалий , погружение в мат.статистику , бан на хабре, непонимание и неприятие коллег и сообщества ...

И вот , похоже первый вариант реально работающей методики - готов . Ну почти готов.

Главное - четкая , понятная и стройная непротиворечивая идея. Хотя конечно, еще очень рано говорить об окончательном решении , но , некоторые моменты внушают осторожный, но твердый оптимизм:
-Расчёты очень простые. Никакой хитрой математики, фокусов и магии. Пара таблиц, несколько хранимых функций .
-Результаты хорошо согласуются с наблюдениями. Чем выше нагрузка и медленнее СУБД - тем ниже значение метрики.

Что можно будет получить в итоге:
-Расчет и анализ производительности отдельного SQL-запроса.
-Расчет и анализ производительности отдельной БД.
-Расчёт и анализ производительности всей СУБД в целом.
-График зависимости производительности тестового запроса( и самое главное - тестовых запросов ) от нагрузки на СУБД. Или другими словами - можно построить график зависимости бизнес функции от нагрузки .
-Адаптивная оптимизация производительности СУБД методом покоординатного спуска . Настройка конфигурационных параметров для конкретной инфраструктуры и характера нагрузки.

Единственно, что пока не понятно - идея лежала на поверхности . Почему никто этим не занимался ?

Товарищ - нервы собери в узду!
Взялся за дело - не охай.
Есть результат - посылай всех в п$зду .
Нет результата - пох$й.


Зачем это все нужно или о необходимости расчета производительности СУБД.

Первый пост Postgresql, Субд, Производительность

Если, что-то неизмеримо в цифрах, этим нельзя управлять и оптимизировать.

Если вы можете измерить то, о чем говорите, и выразить это в цифрах – значит, вы что-то об этом предмете знаете. Но если вы не можете выразить это количественно, ваши знания крайне ограничены и неудовлетворительны. Может это начальный этап, но это не уровень подлинного научного знания.

У. Томсон (лорд Кельвин) шотландский ученый-физик.

Показать полностью 1
Отличная работа, все прочитано!