Комментарии 14
20.09.2024 11:00 - 17:00
21.09.2024 10:00 - 17:00
22.09.2024 10:00 - 17:00
Есть 2 варианта ответа
1) Просто опечатка
2) Закладка на проверку вдумчивого чтения
Спасибо. В любом случае. Хоть, кто-то читает .
На самом деле, очень интересно, спасибо за весь цикл статей
Спасибо за поддержку. На самом деле, мне очень нужна обратная связь, статистику конечно изучал , когда был студентом , но это было очень давно. И к тому, же в то время сильно увлекался ассемблером и C потому и не уделял должного внимания фундаментальным знаниям которые давали бесплатно на тарелочке с голубой каемочкой. Теперь приходится вспоминать и наверстывать. С конструктивной обратной связью на Хабре конечно не очень(просмотры есть, откликов нет, минусов с формулировкой "не согласен" постоянно. Ну если не согласен , то хоть контр довод бы какой), но других технических ресурсов нет. Не в каналы телеграмма же идти ;-) Раньше был еще SQL.RU но он всё.
Может кто обладающий большими знаниями по математике и прочитает и даст реально полезный отклик.
А тема статистического анализа в DBA и вообще анализа производительности СУБД, как выяснилось очень новая. Материалов до обидного мало.
Но , как говорится - дорогу осилит идущий. Так , что тема только в начале исследования. Будет еще много чего интересного.
Ну я вам привел контрдоводы, вы в ответ сказали, что вам недосуг какие-то там приземленные практические примеры рассматривать. И даже отказались объяснять, какую ценность сглаживание результатов измерения TPS с помощью pgbench имеет применительно к каким-либо реальным задачам. Как результат, конечной цели не видно, практической применимости тоже - так откуда бы взяться обратной связи?
Вы ошиблись статьей .
Статья о статистическом анализе производительности - Корреляционный анализ для решения инцидентов производительности СУБД https://habr.com/p/827504/
Эта статья о статистическом анализе нагрузочного тестирования .
В принципе можно было бы собирать и значения TPS формируемые pgbench, но есть пара важных препятствий 1) нужно формировать таблицы вручную 2) и это более важно - TPS считается как среднее а значить сильно подвержено влиянию выбросов. Для анализа результатов использовать цифры выдаваемые pgbench очень рискованно . Особенно на больших промежутках , особенно в облаке .
и это более важно - TPS считается как среднее а значить сильно подвержено влиянию выбросов.
И я вам в третий раз объясняю - тот факт, что метрика производительности подвержена выбросам, совершенно не делает ее непригодной. Напротив - наличие/отсутствие выбросов является критическим фактором при оценке производительности БД, который надо не сглаживать, а, наоборот, включать в анализ.
А другая проблема вашего подхода заключается в самом вашем определении производительности, которое к реальному использованию БД отношение имеет крайне косвенное. Это ваше определение:
Производительностью СУБД называется количество объемов информации, обработанных за единицу времени.
попросту неверно, совсем никак. Потому что производительностью называется не просто количество работы, а количество полезной работы в единицу времени (про КПД слышали ведь?). А полезной работой СУБД являются вовсе не объемы обработанной информации, а возвращение результата посланного к СУБД запроса. И если СУБД А для обработки одного и того же запроса делает втрое больше расчетов и читает/пишет втрое больше, чем СУБД Б, это совершенно не значит, что ее производительность в три раза лучше.
Соответственно, производительностью БД является скорость обработки запросов, для измерения которой и придуман параметр TPS. И вы совершенно верно заметили, что TPS - параметр сам по себе усредненный, и поэтому в единственном числе для измерения производительности не годится. Но вовсе не потому, что он "подвержен выбросам", а ровно по обратной причине - потому что он выбросы сглаживает!
И тут появляется второй параметр - время отклика, который уже оценивается по перцентилям - проценту запросов, попадающий в целевые диапазоны. А эти самые целевые диапазоны берутся из практически приемлемого для клиента БД времени отклика (будь то приложение или непосредственно человек). Вот сидит у вас на БД мобильное приложение, и для него необходимо, чтобы response time на определенные запросы был, условно, в пределах 200мс. Как ваша методика оценки "производительности" поможет понять, норм будет после миграции в облако или в первый же день процентов 5 из 100К клиентов получит вылеты и ошибки и зафлудит техподдержку, а та - вас, если вы целенаправленно (!) пытаетесь выкинуть из оценки пики? "DBA заряжает ружье для выстрела в ногу", холст, масло, Третьяковская галерея.
И вот эта комбинация TPS и Response Time и является показателем производительности БД. Не потому, что в комитете TPC заседают дураки, не знающие, как определяется и меряется производительность и не знающие про матстатистику, а потому, что именно эти показатели ближе всего к мерилу полезной работы OLTP СУБД.
Да, есть еще OLAP, где основанные на TPS методики не подходят напрямую. Там разрабатывают свои, которые, представьте себе, тоже не на pgbench и измерении объемов чтения/записи основаны. А в реальности и нагрузка зачастую вообще смешанная, и паттерны отличаются от тестовых, и в результате любые синтетические измерения могут служить только для первичной прикидки, а дальше надо мониторить целевые показатели, спроектированные под конкретную систему с конкретным окружением.
А вы вместо того, чтобы имеющиеся методики поанализировать и адаптировать под свои нужды, велосипед с квадратными колесами изобретаете.
Ну вот и какой мне смысл с вами вести какое то обсуждение?
У вас кроме imho , эмоций и домыслов - ничего. У вас ни одной статьи по данной предметной области . Что вы вообще обсуждаете ? Если вы не в курсе как выбросы влияют на результаты наблюдений это ваша личная проблема.
Мне интересно обсуждение по теме статьи - статистика, распределение, статистический анализ, критерии нормального распределения , дисперсия, медиана, сглаживание и т.п.
А просто так тереть, мне не интересно. Вам интересно, есть куча других площадок - например телеграм-каналы по PostgreSQL , там примерно ваш стиль общения.
Будет ,что предметно обсудить - пожалуйста , всегда рад интересному и полезному общению, новая информация мне очень интересна.
В общем, как итог - флуд мне не интересен. Прощайте.
:-) Тема то актуальная, но....
"Анализ производительности СУБД" (даже без статистики) интересен "для конкретных условий работы". Условий этих десятки тысяч (начиная от характеристик "железа" х "параметры БД" х "различные профили нагрузки от приложения" х "параметры прикладного софта"). Производительность БД в отрыве от прикладного приложения может учесть только первые два фактора и не факт что максимальная производительность полученная при их оптимизации будет соответствовать максимальной прикладной производительности системы "в целом" (а именно это в большинстве случаев и интересно) + на это накладывается что бизнесу то интересно "минимизация TCO" при допустимо низком % отказа в обслуживании - а это еще более сложно рассчитать...
"Анализ производительности СУБД" (даже без статистики) интересен "для конкретных условий работы"
Именно.
Теперь можно получить базовую производительность СУБД для данной инфраструктуры даже в условиях облачной инфраструктуры - если провести достаточное количество испытаний.
А если по правильному подготовить программу нагрузочного тестирования то можно получить оценки производительности СУБД во составе информационной системы. И в дальнейшем использовать эти оценки для оповещений типа "Alarm performance degradation".
Вообще тема анализа производительности СУБД была начата после постоянно повторяющихся инцидентов "у нас все висит, ничего не работает, все стало медленно". И ВСЕГДА , вот практически 100% со стороны СУБД не проводилось никаких изменений, проблема в инфраструктуре(диски, сеть, антивирусы) и приложении(непрофессиональные разработчики) .
Вот поэтому, что бы иметь четкие математически обоснованные оценки - "С СУБД аномалий нет"
Также, если использовать описываемый подход, то можно сравнить производительность СУБД в разных ИС.
Производительность БД в отрыве от прикладного приложения
В реальности у DBA нет никакой возможности влиять , анализировать и контролировать , что там разработчики на придумывают в этот раз.
Историй - полно. Моя любимая .
ИС тормозит и не показывает показателей заложенный в Техническое решение.
Выясняется - эксклюзивные блокировки pg_adviser_lock
Вопрос разработчикам - вы зачем так делаете ?
Ответ - это не мы, это фреймворк такой.
Так и мучались, через день авария , конфколы, очередное озвучивание причин.
Потом сделали рефакторинг , все работает.
максимальная производительность полученная при их оптимизации будет соответствовать максимальной прикладной производительности системы
Моя зона ответственности СУБД. К сожалению никакого влияния, контроля на администрирование информационной системы у DBA - нет. Как правило воопросами мониторинга информационной системы никто не занимается . В лучшем случае смотря на утилизацию CPU/RAM , начинают беспокоится когда идут сообщения от пользователей.
Для НИИ слишком современно. А для коммерческой разработки слишком оторвано от прикладных задач. Интересно кто за это платит и почему хабр, а не рецензируемое издание по типу Cybernetics & Physics.
почему хабр
По традиции , которая закончилась .
Насчет рецензируемого издания да, это мысль. Эксперименты и исследования продолжаются . А пока для протоколирования промежуточных результатов - ЖЖ. Когда будет собран достаточный материал и математическое обоснование - надо будет искать более серьезный ресурс, взамен Хабра.
Насчет оторванности от прикладных задач вы не правы и просто не в курсе прикладных задач DBA в крупных компаниях.
Уже сейчас есть результаты:
1) Используемая на текущий момент методика проведения нагрузочного тестирования в облачной среде дает недостоверные результаты. Методику надо менять. Уже понятно как , идут эксперименты и анализ результатов.
Вообще теперь понятно , что к публикуемым результатам о проведённых тестах и сравнениях надо относится с большим сомнением . Они статистической не обоснованы как минимум . Следовательно делать изменения и принимать решения на основании недостоверных данных - рискованно .
2) Все используемые инструменты для анализа производительности СУБД, производительность СУБД не анализируют. Следовательно в общем случае бесполезны при анализе причин аварий и деградации СУБД. Что такое производительность СУБД , как измерить - не было методики. Теперь есть.Эксперименты продолжаются . Исследования внесены в стратегические цели развития компании. Возможно результатом станет новый продукт на рынке .
3) Методами статистического анализа производительности и состояния СУБД - никто не занимался . Эксперименты продолжаются . Есть методики по анализу причин деградации производительности СУБД. Стратегическая цель - внедрение и развитие performance engineering в DBA. А это очень прикладная цель, потому, что итогом является оптимизация ресурсов инфраструктуры.
Да, всем чем занимаются дба я не в курсе конечно. Да и не только дба. Работал я в Майкрософте, там у нас на проекте 2 тыс.человек было, я понятия не имел чем занимается подавляющее большинство из них, даже в рамках проекта, не то что компании. Нормально для большой компании. В любом случае хорошо, когда компания выделяет ресурсы на исследования.
Статистический анализ результатов нагрузочного тестирования СУБД в условиях облачной инфраструктуры