Комментарии 9
Большое спасибо за статью и тему. Потребуется более вдумчивое чтение , а пока сразу же вопросы :
профайлер pgpro_pwr, который позволяет анализировать производительность СУБД за определенный период времени
1) Какое определение термина "производительность СУБД" вы используете ?
2) Как рассчитывается и мониторится метрика производительности СУБД ?
Тут правильнее было бы сказать, что PGPRO_PWR помогает оценить производительность и это просто один из инструментов. Если мы исследуем статистику производительности СУБД за определённый период времени, значит у нас есть сомнения/подозрения, что что-то "было не так". Отчёт профайлера помогает найти явные аномалии или самых активных потребителей ресурсов внутри БД, показывает основные ожидания...
Какое определение термина "производительность СУБД" вы используете ?
Как рассчитывается и мониторится метрика производительности СУБД ?
Универсальной метрики "производительность СУБД", к сожалению, не существует. Самые известные "попугаи" для измерений это TPS, но очевидно что надо ориентироваться на требования бизнес-приложения (SLA), следить за ожиданиями/блокировками/запросами в БД и мониторить потребление ресурсов сервера (CPU/Mem/IO). То есть у каждого может быть своё понятие производительности.
Одним словом: производительность СУБД никому не интересна, но всем интересно, насколько быстро работает приложение :-)
Универсальной метрики "производительность СУБД", к сожалению, не существует.
У меня другое мнение - существует, считается, мониторится , статистически анализируется .
производительность СУБД никому не интересна,
В первую очередь интересна для DBA - "с СУБД всё в порядке , разбирайтесь с кривым приложением и проблемами инфоаструктуры ".
Ну как бы конкретную DB в любом случае нужно подстраивать/оптимизировать под специфику прикладного приложения (с учетом доступных ресурсов и профиля нагрузки на нее) и это задача DBA... Другой вопрос что прикладное приложение должно "учитывать особенности реализации конкретной DB", а это сейчас большая проблема для современных прикладных разработчиков которые "по факту" только сторонними фреймворками и умеют пользоваться...
А теперь главный вопрос - какая выгода для информационной системы в целом в результате работ по снижению утилизации CPU с 80 до 60% была получена ?
Какая была производительность СУБД до начала работ и какая стала после ?
После всех изменений утилизация CPU составила приемлемые 50–53%.
1) вы считаете , что производительность обратно пропорциональна утилизации CPU?
2) На основании чего сделан вывод , что 50-53% это приемлемое значение ? А почему не 45% или 62% ?
вы считаете, что производительность обратно пропорциональна утилизации CPU?
Разумеется нет, это не всегда так. Но в данном случае, в результате наших действий удалось значительно увеличить ключевые метрики бизнес-приложения. Можно назвать их "количество обработанных/проведённых документов в единицу времени".
На основании чего сделан вывод, что 50-53% это приемлемое значение ? А почему не 45% или 62% ?
Приемлемое, в нашем случае, относительно исходных значений, меньше которых нам получить не удалось. Если бы это было 10% мы бы тоже не обиделись :-)
И сложно сомневаться, что если программа может выполнить больше работы, используя меньшее количество ресурсов и оставить запас под будущие нагрузки, это плохо.
программа может выполнить больше работы
Работа это фундаментальное физическое понятие. Что вы имеете в виду когда говорится о работе выполненной программой ?
Я, конечно, не физик, однако работы нет в списке фундаментальных понятий и величин т.к. её определение зависит исключительно от раздела физики, в котором оно рассматривается. Фундаментальные вещи себя так не ведут и всегда однозначны, иначе какие же они фундаментальные.
Да и у нас тут не кружок юного физика, чтобы притягивать за уши определения из других дисциплин. Но раз вам это так принципиально, давайте обратимся к обратной стороне луны - наукам гуманитарным. Возьмём словарь Даля и посмотрим на определение термина "работа", как совершенно очевидного синонима слова "труд". Получаем: "все, что требует усилий, старанья и заботы; всякое напряженье телесных или умственных сил". Кажется всё очевидно, но это же гуманитарии и что они вообще толкового могут сказать, правда? Тогда давайте обратимся обратно к строгой науке физике, где, например, Ожегов даёт нам такое определение этого таинственного термина: "Процесс превращения одного вида энергии в другой".
На этом предлагаю остановиться, договорившись что работа программы это прекращение энергии электрической, в энергию причинения бизнес-результата с конвертацией в деньги.
С заботой о CPU: как найти узкое горлышко и сконфигурировать Postgres Pro