Серия «СУБД 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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

Как минимум:

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

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

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

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

ВМ-1

CPU Utilization

Commited transactions

ВМ-2

CPU Utilization

Commited transactions

Итог

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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