Архивный материал. Описанные методики или устарели или не используются.
В качестве завершения попыток проанализировать влияние версии СУБД или ОС на производительность СУБД в облачной инфраструктуре.
Завершение цикла
Конфигурация виртуальных машин
ВМ-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
ВМ-3
Postgres Pro (enterprise certified) 16.4.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Soft 11.4.0-1), 64-bit
CPU = 24
RAM = 29
ОС = RED 7.3
Тестовый запрос
UPDATE pgbench_accounts SET abalance = abalance + 10 WHERE aid = 500 ;
Нагрузка pgbench растет экспоненциально от 5 до 687 одновременных соединений.
Результаты по данным метрики Committed transactions в Zabbix
ВМ-1
- Среднее = 1.66K
- Максимальное = 3.93K
ВМ-2
- Среднее = 382.45
- Максимальное = 795.7789
ВМ-3
- Среднее = 363.8492
- Максимальное = 755.2441
Итог
Производительность СУБД в облачной инфраструктуре определяется не версией СУБД и не версией ОС, а настройками и конфигурацией виртуализации.
Дальнейшие работы по сравнению производительности СУБД расположенных в разных виртуальных машинах - завершены, как не имеющие практической ценности .
Сравнивать и анализировать можно только отдельную СУБД при изменяющейся нагрузке и разных сценариях тестирования .
Проблема в том, что , я как DBA не имею никакой информации и влияния намнастройки виртуальных машин в облачном хранилище. Можно потратить массу времени на тонкий тюнинг или сделать вывод о эффективности версии СУБД, но после очередной смены гипервизоры или изменениях в СХД характер производительности сменится кардинально.