Конференция

18:30–19:15 — доклад эксперта МТС Александра Якунина «Невидимая рука предубеждений в архитектуре ПО: как распознать и смягчить скрытые издержки»

• Автор расскажет о частых когнитивных и организационных искажениях, рассмотрит примеры провалов и предложит методы на основе анализа данных и правильной организационной культуры.

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

19:15–20:15 — перерыв, кейтеринг и нетворкинг

19:30–20:00 — демо стендов (2-й этаж)

20:15–21:00 — доклад приглашенного эксперта Игоря Морозова «ИИ в автоматизации и интеграции»

• Узнайте, как композитная и MACH-архитектура позволяют быстрее внедрять ИИ-агентов.

• И как развитие ИИ сказывается на области интеграций и автоматизации.

21:00–21:15 — завершение, результаты игр

21:15–22:00 — нетворкинг

Чтобы узнать о событии больше, подпишитесь на открытый канал архитектурных новостей и вступите в его чат.

Erid: 2VtzqvQpkHv

18 марта 2025 года Московский завод тепловой автоматики принял участие в 5-й Международной научно-практической конференции «Автоматизированные системы управления технологическими процессами» (Control-2025). Мероприятие прошло в Национальном исследовательском университете «МЭИ», на котором с докладом «Открытая шина данных АСУ ТП» выступил советник Генерального директора МЗТА по разработке ПО Андрей Походня.

Приводим презентацию «Открытая шина данных АСУ ТП» и видео выступления (в конце статьи). Вопросы к докладчику касались как сроков реализации проекта создания OCF-шины, так и технических деталей, таких как обработка сигналов различной природы в реальном режиме времени.

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

Альтернативные варианты названия

1. Статистический анализ производительности СУБД PostgreSQL.

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

3. Корреляционный анализ для решения инцидентов производительности СУБД PostgreSQL

Описание контекста

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

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

Для этого необходимо уметь рассчитывать/сравнивать/анализировать производительность СУБД.

Основная идея

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

· количество запросов в секунду

· количество зафиксированных транзакций

· среднее время отклика СУБД

· и даже процент утилизации CPU+RAM

· или некая магия, получаемая если посмотреть на экран на котором десяток другой графиков мониторинга

Так руководствуясь некими рецептами алхимиков, DBA каким-то мистическим образом определить хорошо работает СУБД или плохо.

Ситуацию нужно менять. И на помощь, придет то, что всегда помогает инженерам – математика.

Структура доклада

Зачем нужно считать производительность СУБД

Вопросы, для ответа на которые, требуется рассчитать производительность СУБД в виде метрики:

· Что такое "хорошо" и что такое "плохо" когда вопрос касается производительности СУБД?

· На сколько "лучше" или "хуже" стало СУБД после того как изменили что-то?

· "Мы уперлись в СУБД " – а точно со стороны инфраструктуры и приложения нет проблем и узкое место информационной системы — это СУБД?

Как рассчитать производительность СУБД и какие проблемы возникают

· Известные аномалии расчета метрики производительности.

Итог:

Рассчитать производительность СУБД в физическом смысле нельзя. Но можно оценить по косвенным показателям, используя метрики оценки производительности СУБД.

Инструменты мат. статистики, используемые при расчетах

· Медиана

· Коэффициент корреляции

Метрики и индикаторы производительности СУБД

· Операционная скорость

· Количество ожиданий СУБД

· Количество ожиданий СУБД по типам ожидания

· Относительная доля ожидания

· Корреляция активных сессий и операционной скорости

· Корреляция операционной скорости и ожиданий

Корреляционный анализ ожиданий СУБД

· Основная гипотеза корреляционного анализа ожиданий СУБД

· Последовательность действий(алгоритм)

Сценарии и анализ результатов нагрузочного тестирования СУБД.

Одного сценария нагрузочного тестирования – недостаточно.

Проблема среднего арифметического при расчёте среднего времени выполнения запроса.

Сценарии нагрузочного тестирования:

· Сценарий №1 – SELECT ONLY

· Сценарий №2 – SELECT + UPDATE (TCP-B)

· Cценарий №3 – INSERT ONY

· Cценарий №3 – HEAVYWEIGHT LOAD CPU

Практические примеры решения инцидентов производительности СУБД с использованием корреляционного анализа

О чем можно будет узнать из доклада

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

О чем не будет сказано в докладе

“Best practices” при использовании корреляционного анализа ожиданий СУБД

Очень разные варианты инфраструктуры и профили нагрузки на СУБД.

Внутренняя структура сервисной БД и подробный алгоритм расчетов.

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

Наличие “Know-How”.