User
Мысли вслух
Если параметр для организации «честной/справедливой» очереди легковесных блокировок в Postgres Pro действительно позволяет решить проблему с ростом очереди ожиданий LWLock, почему значение параметра lwlock_shared_limit по умолчанию 0, а не 16?
Какие риски возникают при увеличении значения параметра lwlock_shared_limit?
Хорошо, если возможность проведения нагрузочного тестирования. Но, в продуктиве уже нет такой возможности.
И как оценить риски?
Современный стиль разработки информационных систем это:
Переживать за закрытие этапов договора , а не за качество, производительность и отказоустойчивость продукта .
Современный стиль разработки информационных систем это:
На этапе разработки назначить права суперпользователя ролям БД и потом громко возмущаться, когда права изымаются в процессе передачи СУБД в поддержку.
Современный стиль разработки информационных систем это:
Спроектировать и запустить в продакшн высоконагруженную СУБД, в которой транзакция,изменяющая ключевую таблицу, завершается по сигналу от внешней информационной системы(по протоколу http).
И получить в результате постоянную очередь ожиданий и деградацию производительности в случае проблем с внешней системой и/или проблем с сетью.
Современный стиль разработки информационных систем это:
Воспринимать СУБД как черный ящик для хранения данных
Не привлекать DBA к процессу дизайна и разработки
Использовать ORM для взаимодействия с СУБД
Не анализировать коды ошибок СУБД
Не проводить нагрузочное тестирование
Пытаться решать проблемы деградации производительности информационной системы путем подбора магической комбинации конфигурационных параметров СУБД или увеличения железных ресурсов для БД.
В общем, как в песне поется -"Раз-раз, и в продакшн"
Мониторинг производительности СУБД в промышленной эксплуатации имеет ли смысл?
Информационная система введена в промышленную эксплуатацию.
Какие могут быть причины снижения производительности СУБД:
Проблемы с инфраструктурой.
Криворукие разрабы начали эксперименты в продуктивном контуре.
Администраторы системы не рассчитали систему на повышенную нагрузку со стороны пользователей.
Проще говоря причины снижения производительности СУБД всегда внешние и не могут быть решены никакими волшебными серебряными пулями в настройках СУБД. Все эксперименты по оптимизации надо было делать при нагрузочном и стресс тестировании.
А если так — какой смысл мониторить производительность СУБД?
Кроме чисто академического.
Как выяснилось, в 15-й версии PostgreSQL внесено новое изменение в инструкцию CREATE DATABASE (стратегия), существенно влияющее на поведение СУБД . Новая фича сделана по умолчанию, и для того, чтобы работало как раньше - нужно менять текст инструкции.
В результате, после обновления до 15-й версии , возникли очень существенные проблемы, вплоть до аварии СУБД.
IMHO решение выглядит нарушением принципа совместимости снизу вверх.
В продолжении https://habr.com/ru/posts/787966/
Интересно, а будет ли иметь какой то практический смысл использование скользящих средних для анализа производительности СУБД.
Например классический сигнал на продажу - как сигнал о деградации производительности ?
Нет ни одного открытия, ни в технологии, ни в методах управления, одно только использование которого обещало бы в течение ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения.
Фредерик Брукс — американский учёный в области теории вычислительных систем, автор книги «Мифический человеко-месяц». Управлял разработкой OS/360 в IBM. Награждён Премией Тьюринга в 1999 году.
Как оценить производительность СУБД в целом ? Как сравнить производительность СУБД в течении времени ?
А может быть производительность СУБД это вектор: (N1, N2, N3), где:
N1 - количество активных сессий
N2 - количество транзакций
N3 - количество запросов к СУБД в секунду.
Тогда можно получить модуль вектора , как квадратный корень из N1^2 + N2^2 + N3^2 , и уже сравнивать изменение значения и собирать историю.
Затем , построить метрику , и вообще применить механизм статистического анализа - скользящее среднее и т.п.
Почему они это делают? Или очередной риторической вопрос.
Интересная особенность современного поколения разработчиков - они очень любят эксклюзивные блокировки.
1) select ... for update - "самый распространенный вариант"
2) pg_advisory_lock - "у нас фреймворк такой"
В результате - стандартная ситуация, которой лет 30, если не больше - "на тесте все работает, а в продуктивном контуре, при реальных пользователях нет".
Я в СУБД с 97-го года , пока не могу представить сценарий при котором , в современных СУБД нужна эксклюзивная блокировка строк и таблиц, особенно в высоконагруженной OLTP.
Наверное мои знания и представления о современной разработке для СУБД несколько устарели.
Компания решает выполнить решение государства о переходе на отечественное ПО.
Как обстоят дела сейчас:
Ищется поставщик решения , параллельно пишется техническое решение/пояснительная записка с максимальной размытыми формулировками и цифрами с потолка.
Поставщик решения разрабатывает решение , в компании формируется проектная команда, формируется инфраструктура.
Поставщику решения главное - получить оплату по договору.
Проектной команде - закрыть этапы и KPI.
Нагрузочное тестирование проводится в режиме - для галочки. Можно вообще в продакшн выводить без НТ.
Стресс тестирование проводится - никак.
Результат - ХYZовый код: "у нас проблемы после перехода на отечественное ПО". Потому, что поставщик решения один и качество ему не важно от слова вообще. В случае проблемы, все списывается на "у вас с инфраструктурой проблемы, у нас на тестовом сервере все работает"
Как было бы лучше:
Формируется проектная команда.
Проектная команда определяет доступные ресурсы инфраструктуры.
Проектная команда формирует требования к решению.
Объявляется конкурс.
Поставщики готовят решения.
Проводятся сравнительные испытания.
По итогам испытаний выбирается поставщик решения для компании.
Результат — побеждает сильнейший и качественный продукт.
Стратегия давно реализована и применяется госзаказах и конкурсах между разными КБ. В результате получаются отличные изделия которыми можно гордится.
Почему не реализовано в IT ? Это риторический вопрос.