Лига Новых Технологий

Взято с основного технического канала Postgres DBA

Предисловие и предыстория

Рgpro_pwr — инструмент стратегического мониторинга нагрузки на базу данных, который помогает DBA выявлять самые ресурсоёмкие операции.

pg_profile и pgpro_pwr: анализируем производительность БД

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

Задачи решаемые на оперативном уровне:

1. В каком состоянии находится производительность СУБД в данный момент времени?

2. Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

3. На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

Задачи тактического уровня:

1. Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?

2. Какой/какие SQL запросы оказывают наибольшее влияние на снижение производительности ?

Предпосылки создания инструмента pg_hazel.

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

В ходе предварительных исследований были проверены разные способы расчета метрики производительности СУБД .

Подробнее здесь: Производительность СУБД PostgreSQL — расчет метрики, временной анализ, параметрическая оптимизация

Однако , методы описанные в статье , к сожалению имеют свои аномалии.

Теоретически, наиболее близким к физическому определению производительность системы будет объемная скорость информации переданной клиенту , или другими словами - объем строк переданных запросом. Но к сожалению, на текущий момент , получить такую информацию - нет технической возможности. Важно - количество строк в запросе это не объем. Длина строки внутри выборки может меняться в очень широких диапазонах.

Поэтому было принято решения - непосредственный расчет производительности СУБД как физической величины - отложить на будущее, до реализации механизма получения объема данных переданных запросом.

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

Структура pg_hazel

Источником данных являются представления расширения pgpro_stats

G.3.4.1. Представление pgpro_stats_statements

Статистика, собираемая модулем, выдаётся через представление с именем pgpro_stats_statements. Это представление содержит отдельные строки для каждой комбинации идентификатора базы данных, идентификатора пользователя и идентификатора запроса

G.3.4.2. Представление pgpro_stats_totals

Агрегированная статистика, собранная модулем, выдаётся через представление pgpro_stats_totals. Это представление содержит отдельные строки для каждого отдельного объекта БД

Данные собираются ежеминутно и агрегируются на 3-х уровнях:

1. Уровень Кластера

2. Уровень Базы Данных

3. Уровень SQL запроса

Дополнительные данные pg_hazel

Как было указано ранее данные о среднем времени выполнения запроса собираемые в расширениях pg_stat_statements или pgpro_stats имеют очень серьезную проблему - среднее арифметическое не устойчиво к выбросам.

Подробнее здесь О проблеме использования mean_exec_time при анализе производительности PostgreSQL

Поэтому для корректного расчета среднего времени выполнения запроса используется не среднее арифметическое , а медиана.

К сожалению, расчет проводимый на уровне БД требует специальной подготовки для тестового запроса и дополнительных ресурсов для хранения и статистического анализа данных. Поэтому применяется не для всех SQL запросов а только для конкретных тестовых запросов:

1. Benchmark кластера - медианное время выполнения тестового запроса для оценки производительности кластера в целом.

2. Тестовый запрос стресс-тестирования - медианное время выполнения запроса по выбранному сценарию в ходе проведения стресс-теста(нагрузочного тестирования)СУБД.

Данные собираемый pg_hazel

1. Уровень Кластера

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

2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.

3. Активные сессии - количество активных сессий на точку времени.

4. Ожидания - количество событий ожидания СУБД за период.

5. BUFFERPIN - количество событий ожидания bufferpin за период.

6. EXTENSION - количество событий ожидания extension за период.

7. IO - количество событий ожидания io за период.

8. IPC - количество событий ожидания ipc за период.

9. LOCK - количество событий ожидания lock за период.

10. LWLOCK - количество событий ожидания lwlock за период.

11. WAITING_RATIO - относительная доля ожиданий СУБД в общем времени работы СУБД за период.

12. CORRELATION - коэффициент корреляции между количеством активных сессий и операционной скоростью.

13. BENCHMARK - медианное время выполнения тестового запроса.

14. CPI - комплексный индикатор производительности = Операционная скорость / BENCHMARK .

2.Уровень Базы данных

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

2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.

3. Активные сессии - количество активных сессий на точку времени.

4. Ожидания - количество событий ожидания БД за период.

5. BUFFERPIN - количество событий ожидания bufferpin за период.

6. EXTENSION - количество событий ожидания extension за период.

7. IO - количество событий ожидания io за период.

8. IPC - количество событий ожидания ipc за период.

9. LOCK - количество событий ожидания lock за период.

10. LWLOCK - количество событий ожидания lwlock за период.

11. WAITING_RATIO - относительная доля ожиданий БД в общем времени работы БД .

3.Уровень SQL запроса

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

2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за за период .

3. Активные сессии - количество активных сессий на точку времени.

4. Ожидания - количество событий ожидания SQL запроса за период.

5. BUFFERPIN - количество событий ожидания bufferpin за период.

6. EXTENSION - количество событий ожидания extension за период.

7. IO - количество событий ожидания io за период.

8. IPC - количество событий ожидания ipc за период.

9. LOCK - количество событий ожидания lock за период.

10. LWLOCK - количество событий ожидания lwlock за период.

11. WAITING_RATIO - относительная доля ожиданий SQL запроса в общем времени работы SQL запроса .

Важное уточнение

Для данных используется медианное сглаживание - короткий период 10 минут , долгий период 60 минут.

Примеры практического применения и анализа на основе собранных данных - в следующих статьях.

Хотите чистой правды? Заваривайте чай, желательно с пустырником, валерьянкой или зверобоем, запасайтесь формулой СтрессРелив, усаживайтесь поудобнее и можете приступать к чтению.

В начале 2025 года мы от Центра Технологий Здоровья приняли участие в крупнейшей мировой технологической выставке CES 2025 в Лас-Вегасе, США, где представили наше устройство мониторинга состояния общего здоровья RaDoTech.

Впечатления, конечно, не самые положительные. А больше всего удивляет, что в заказных (судя по всему) обзорах выставки, представленные там умные технологии являются действительно чем-то гениальным. Но давайте обо всем по порядку.

Несмотря на то, что наше устройство привлекло интерес крупных компаний, в том числе таких как Samsung и LG, общее впечатление от выставки, от секции Digital Health, оказалось крайне негативным. Вместо ожидаемых инноваций в области цифрового здоровья, мы столкнулись с обилием бесполезных гаджетов, которые, по сути, ничем не помогают пользователям быть здоровее.

"Вместо действительно полезных разработок, я увидел множество стендов с цифровыми "дрочилками" на базе искусственного интеллекта, множество массажных кресел, мобильную беговую дорожку, десятки устройств с красным светом и бесчисленные умные кольца, которые измеряют те же показатели, что и обычные смарт-часы", - прокомментировал Игорь Берлинский, генеральный директор CeTeZ.

Особенно возмутили проекты, якобы определяющие уровень сахара в крови или вероятность развития заболеваний по дыханию. При дотошном опросе представителей, выяснилось, что эти решения не обладают достаточной точностью и доступны к покупке лишь для врачей, а не для конечных потребителей.

"Я пытался задавать уточняющие вопросы, но разработчики сразу прекращали со мной общение, уточняя являюсь ли я инженером, а стоило только упомянуть, что я Технолог Здоровья - почти выгоняли со стенда. Видимо, им нечего было ответить на мои вопросы", - рассказывает Игорь.

Тем не менее, на выставке были представлены и действительно интересные медицинские разработки, относящиеся к категории "цифровой медицины". Однако, по нашему мнению, это направление, опять же, больше ориентировано на врачей, а не на рядовых пользователей.

"Цифровое здоровье - это то, что человек может использовать самостоятельно для себя. А если решение требует участия врача, то это уже цифровая медицина. К сожалению, таких действительно полезных для людей проектов на CES в секции Digital Health практически не было", - резюмирует Игорь.

В итоге, вместо ожидаемого "светлого будущего" в области цифрового здоровья, мы столкнулись с разочаровывающей картиной технологической выставки, заполненной бесполезными гаджетами и непрозрачными решениями. Честно говоря, заставляет усомниться в адекватности многих разработчиков, представленных на CES 2025 в нашей профильной секции.

Все эти "няшные устройства", которыми сейчас буквально пестрит рынок, на самом деле дают людям абсолютно бесполезные, но красивые и интересные данные. Они приучили пользователей к бездумным действиям, не влияющим на здоровье. Человек просто надевает, ставит или прикрепляет очередной гаджет, а тот выдает ему "дофаминчик" в виде информации о выпитой воде, сделанных шагах и прочих малозначимых показателях. После этого люди с чувством выполненного долга идут поглощать очередной гамбургер.

Но когда эти же посетители выставки сталкиваются с нашим решением - RaDoTech, у них возникает ощущение, что для его понимания необходимо как минимум учиться на третьем курсе медицинского вуза. Сложность и глубина наших Технологий Здоровья кажется им просто космической на фоне примитивных фитнес-трекеров.

Сейчас перед нами стоит непростая задача - как сделать нашу емкую, но по-настоящему полезную технологию более доступной для широкой западной, и не только, аудитории. Одно из решений, которое пришло в голову после всех событий - это сопровождение пользователей RaDoTech удаленно, через чат-ботов или операторов. Тогда люди не будут предоставлены сами себе с многообразием рекомендаций и аналитики, а получат персональную поддержку в интерпретации результатов и дальнейших действиях.

Очевидно, что производители высокотехнологичных устройств для здоровья сталкиваются с непростой задачей - найти баланс между простотой использования и глубиной предоставляемых данных. Решение этого вопроса позволит сделать передовые разработки по-настоящему массовыми и доступными. Именно над этим мы сейчас активно работаем в CeTeZ.

«Несмотря на текущее положение дел в индустрии, я вижу подтверждение огромных перспектив для нашего продукта и необходимость продолжать работу над его развитием.» — Игорь Берлинский, генеральный директор Центра Технологий Здоровья CeTeZ, создатель прибора RaDoTech для мониторинга здоровья, доктор технических наук, академик Европейской Академии Естественных наук, Профессор в Гонконгском научно-исследовательском институте гуманитарных и естественных наук и технологий.