Часть 2 - Сценарий нагрузочного тестирования "OLTP"
Выбирай сердцем
Задача эксперимента
Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .
СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.
Сценарий "OLTP"
Тестовый запрос состоит только из выражений SELECT - UPDATE.
Все блоки использующиеся в запросе - находятся в распределенной области.
Для создания нагрузки используется pgbench.
Количество сессий к СУБД растет экспоненциально для каждого прохода теста.
Производительность СУБД
Разница производительности от 5-9%
Относительная разница производительности OS-1 и OS-2
Время выполнения тестового запроса
Разница времени выполнения тестового запроса от -5% до 7%
Относительная разница времени выполнения тестового запроса
Итог
Для сценария "OLTP", при нагрузке до 111 сессий - производительность СУБД развернутой на ОС Linux версии OS-1 превосходит производительность СУБД развернутой на ОС Linux версии OS-2 на 5-9% .
Судя по полному отсутствию найденных материалов по применению математического аппарата для задач администрирования баз данных - современные администраторы баз данных в лучшем случае художники , а как правило ремесленники.
За столько лет , организация работы обычного DBA не сильно изменилась.
Обсуждение с коллегами показало - полное отсутствие интереса и полное непонимание - в чем сила и смысл использования математических методов.
К сожалению пока не нашёл ничего полезного, по использованию таких базовых математических понятий как "мат.ожидание" , "стандартное отклонение" , "дисперсия", "коэффициент корреляции" для администрирования баз данных. В первую очередь для анализа производительности баз данных.
Да, что там, даже нет четкого математического определения- что считается производительностью базы данных и как измерять.
А ведь в сущности нормальная работа администратора баз данных состоит в анализе результатов наблюдений.
Наблюдение и анализ данных - основа инженерного подхода к делу.
Странно , но почему то, стандартные методики анализа, успешно применяемые в других технических областях, в DBA - не используются.
Что ж , тем интереснее будет на чистом листе . Может , кому и пригодится и поможет в итоге. Для себя то уже есть первые результаты , но пока надо все аккуратно сформулировать и оформить. И конечно - набирать статистику наблюдений.
Часть 1 - сценарий нагрузочного тестирования "Select only"
Какой Linux выбрать ?
Задача эксперимента
Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .
СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.
Сценарий "Select only"
Тестовые запрос состоит только из выражения SELECT.
Все блоки использующиеся в запросе - находятся в распределенной области.
Для создания нагрузки используется pgbench.
Количество сессий к СУБД растет экспоненциально для каждого прохода теста.
Производительность СУБД
Разница производительности от 10 до 13%
Относительная разница производительности OS-1 и OS-2
Время выполнения тестового запроса
Разница времени выполнения тестового запроса до 7%
Относительная разница времени выполнения тестового запроса
Итог
Для сценария "Select only", при нагрузке до 111 сессий - производительность СУБД развернутой на ОС Linux версии OS-1 превосходит производительность СУБД развернутой на ОС Linux версии OS-2 не менее чем на 10% .
Статья не о сравнении ОС, задача статьи - тестирование методологии сравнения производительности СУБД.
Задача
Имеется 2 виртуальных машины с развернутой СУБД PostgreSQL.
Версия СУБД - одинаковая.
ОС - одинаковая. Гипервизор - один.
Различие - системный диск HDD vs. SSD.
Необходимо количественно определить влияние расположения файлов ОС на производительность СУБД. Т.е. определить разницу в накладных расходах для создания серверного процесса для нового соединения .
Реализация эксперимента - сценарии нагрузки
Для оценки производительности и среднего времени выполнения тестового запроса используются 3 сценария нагрузки:
Select only (условный сценарий WEB): нагрузка в виде запроса .
TPC-B (условный сценарий OLTP): Нагрузка в виде транзакции состоящей из UPDATE-SELECT
Heavyweight (условный сценарий DSS): Нагрузка в виде тяжелого запроса SELECT..JOIN..ORDER BY + вычислительная нагрузка
Индекс производительности СУБД(CPI) : операционная скорость
Время выполнения тестового запроса: скользящая медиана с периодом 1 час.
В декабре Оксфордский словарь признал "brain rot" (буквально "гниение мозга") словом года.
Про brain rot писали многие СМИ, но казалось, что это фигуральное выражение. Мол, если потреблять гору бессмысленного контента, то мы деградируем, и мозг "портится".
Но в мой пока ещё не совсем сгнивший (надеюсь) мозг закралось подозрение, что здесь есть более глубокий смысл. Я копнул и выяснил, что от тиктоков, шортсов и рилсов мозг гниёт в очень даже ПРЯМОМ СМЫСЛЕ. Алгоритмическая контентная жвачка ослабляет наше серое вещество в буквально, биологически. И вот как это работает:
В нашем мозге есть механизм под названием "хабенула" (иногда её называют уздечкой). Находится она в эпиталамической, задней части мозга. Это такая небольшая структура размером с горошину. Но у неё очень важная функция - по сути, это соединительный шлюз между разными отделами мозга, который регулирует и балансирует всю нашу систему вознаграждения.
Примерно так это выглядит.
Если активность нейронов хабенулы снижена, то человек склонен подсесть на вещества. А если наоборот, чрезмерно повышена, то человек не может испытывать удовольствие, и у него с большой вероятностью разовьётся депрессия. Здесь я описал очень упрощенно - чтобы показать суть, что эта маленькая штука в мозге очень-очень важна (подробнее можете почитать вот тут, например).
Так вот, работа хабенулы - это важный механизм. Однако, эволюция не учла, что человеки научатся скроллить тиктоки. Когда мы бесконечно пичкаем мозг безлимитным потоком не обременённого смыслом "прокрастинационного" контента, хабенула начинает ловить жёсткие глюки. Она просто не понимает, как действовать, потому что мозг получает бесконечную дозу дешёвого дофамина, лже-удовольствия.
Ну вы поняли...
В итоге, регулярный скроллинг ленты может очень серьезно расстроить (в смысле не "огорчить", а "сломать") всю работу этой системы. А если у человека сломалась хабенула, то он:
- Не может состредоточиться и сфокусироваться. Концентрация становится непозволительной роскошью.
- Не может долго и интеллектуально работать, решать сложные задачи. Да даже посмотреть длинный обучающий видос на Ютубе становится непосильной задачей.
- Испытывает одиночество и скуку, потому что не может "провалиться в поток" какого-то занятия. С отношениями и семейной жизнью у таких людей тоже всё непросто.
- Склонен к думскроллингу, и далее к депрессии.
- Да вообще ничего хорошего его не ждёт. Кроме новой порции дофамина от скроллинга, ведь если человек разучился фокусироваться, то остаётся лишь прокрастинировать.
В общем, brain rot - это не шутка. Это серьёзное негативное явление, которое сильно меняет наш мир прямо сейчас. Как там говорят: "Мир развалится, когда умрёт последний бумер"?
Но лично я думаю, что не всё потеряно. Да, тиктоки и алгоритмические ленты стали частью нашей жизни, и никуда они не денутся. Но мы всё ещё хозяева своего свободного времени. Лимитируйте время внутри ленты, ставьте таймеры и будильники, смотрите фильмы, читайте книги и общайтесь с родными БЕЗ ТЕЛЕФОНА. Ещё как вариант - приоритизируйте Телеграм над другими площадками. В Телеге нет ленты (большое спасибо за это П. Дурову), и потребление контента куда более осознанное. Надеюсь, так оно и останется.
Больше про нашу цифровую реальноть в моей Телеге, заходите (там точно нет алгоритмических лент и брейнрота).
Москва, Россия – В минувшие выходные на территории олимпийского велотрека Крылатское прошла масштабная презентация нового адаптивного трехколесного электротранспорта TRITOM. Это событие собрало множество гостей, среди которых были представители Молодой Гвардии Единой России, ассоциация водного велотуризма, медиахолдинг Регионы России, врачи–реабилитологи, ветераны СВО и люди с ограниченными физическими возможностями.
TRITOM - адаптивный электротранспорт
Презентация TRITOM прошла на фоне знаменитого велотрека, который не раз становился свидетелем выдающихся спортивных событий. Участники мероприятия получили уникальную возможность протестировать новый транспорт прямо на олимпийском полотне, что добавило особую значимость и атмосферу мероприятию.
велотрек Крылатское построен к Олимпиаде 80
Гости были в восторге от простоты управления трехколесным электротранспортом, его динамики и комфорта при поездке. TRITOM спроектирован с учетом потребностей людей с ограниченными физическими возможностями, что делает его идеальным решением для всех, кто ищет свободу передвижения и активный образ жизни.
«Мы уверены, что TRITOM станет незаменимым помощником для многих людей, открывая новые горизонты и возможности», – отметил представитель компании–разработчика.
Презентация электротранспорта TRITOM на велотреке Крылатское стала ярким событием, подчеркнувшим важность инклюзивных технологий и их роль в улучшении качества жизни людей с ограниченными возможностями. Все участники с нетерпением ждут будущих инноваций и возможностей, которые этот проект может принести.
Для тестирования использовался именно этот сценарий .
Конфигурация виртуальных машин
ВМ-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 существенно выше ВМ-2
Т.е. по итогам данного теста получается - СУБД развёрнутая по шаблону ВМ-1 будет существенно производительнее ?
Что будет , если архитектор примет решение о выборе версии СУБД и запланирует ресурсы инфраструктуры на основании только данного теста ?
Решение проблемы
Одного теста для анализа производительности СУБД и ВМ - недостаточно.
Как было указано в документации:
Однако вы можете легко протестировать и другие сценарии, написав собственные скрипты транзакций.
Что и было сделано.
Для продолжения тестов, был подготовлен сценарий требующий серьезных вычислительных ресурсов - SELECT ... JOIN
Результат тестирования тяжелого запроса
ВМ-2 СУЩЕСТВЕННО производительнее чем ВМ-1
Все встало на свои места.
ВМ-1 даже не хватило ресурсов при количестве одновременных запросов свыше 160. При этом производительности ВМ-2 существенно выше производительности ВМ-1.
Итог
Нельзя принимать архитектурных решений на основании результатов одного только сценария нагрузочного тестирования
2. Для оценки производительности архитектурного решения по конкретной СУБД необходим комплекс разных сценариев нагрузочного тестирования.
Как минимум:
-Select only: оценка скорости чтения данных из СУБД
-Standard: оценка производительности СУБД в условиях конкуренции за блокировки.
-Heavyweight: оценка производительности СУБД при выполнении тяжелых вычислительных и ресурсоемких операций.
