Postgresql + Производительность

Предисловие

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

Задача

Имеется 2 виртуальных машины с развернутой СУБД PostgreSQL.

Версия СУБД - одинаковая.

ОС - одинаковая. Гипервизор - один.

Различие - системный диск HDD vs. SSD.

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

Реализация эксперимента - сценарии нагрузки

Для оценки производительности и среднего времени выполнения тестового запроса используются 3 сценария нагрузки:

1. Select only (условный сценарий WEB): нагрузка в виде запроса .

2. TPC-B (условный сценарий OLTP): Нагрузка в виде транзакции состоящей из UPDATE-SELECT

3. Heavyweight (условный сценарий DSS): Нагрузка в виде тяжелого запроса SELECT..JOIN..ORDER BY + вычислительная нагрузка

• Индекс производительности СУБД(CPI) : операционная скорость

• Время выполнения тестового запроса: скользящая медиана с периодом 1 час.

• Максимальная нагрузка: 100 одновременных запросов.

• Рост нагрузки: экспоненциально, с коэффициентом 0.2

Результаты эксперимента

Select only

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

Время выполнения тестового запроса

Итог по сценарию Select only :

Производительность СУБД - практически не отличается.

TPC-B

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

Время выполнения тестового запроса

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

Производительность СУБД - практически не отличается.

Heavyweight

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

• До 54 соединений: разница производительности не превышает 3%

• 65 - 93: Производительность ВМ2 выше до 17%

• 111 соединений: резкая деградация производительности . Производительность ВМ2 на 21%

Время выполнения тестового запроса

• До 45 соединений: разница времени выполнения не превышает 2%

• с 54-111 соединений: Время выполнения тестового на ВМ2 увеличивается до 9%

• 111 соединений: резкое увеличение времени выполнения тестового запроса. Время выполнения тестового на ВМ2 больше на 22%

Итог по сценарию Heavyweight

При сравнительно небольших нагрузках (до 45-54 соединений) производительность ВМ1 и ВМ2 не отличается.

При высоких нагрузках (54 и более) производительность ВМ2 выше. Однако и время выполнения тестового запросы тоже выше.

Общий итог

1.Только при использовании разных сценариев нагрузки можно получить полную картину производительности СУБД .

2. Для ОС использованной в тесте , при невысокой нагрузке на СУБД, расположение системного диска на HDD или SSD - несущественно .

Проблема

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

Причина

По умолчанию 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 и низкая производительность СУБД в рабочее время — зря потраченные средства.