Добрый вечер, возник следующий вопрос - допустим значение bgwriter_lru_maxpages (или значение другого параметра) слишком большое, возникнут ли какие либо ожидания ?
Или другими словами - возможно от определить , что настройка контрольной точки оптимальна ?
Отсюда и идея использовать манхэттенскую метрику. Одновременное чтение 1 ед/с и запись 1 ед/с создают "расстояние от центра" (суммарную нагрузку) в 2 ед/с.
В случае RAID-5 дисков, а также SSD-накопителей также нужно учесть, что запись в них происходит намного медленнее считывания.
Ещё раз спасибо .
Казалось , бы вполне очевидное замечание. Но с очень далеко идущими последствиями.
Например - если назначить вес для операции записи больше чем операции чтения , метрика производительности при большем количестве записи будет меньше .
Осталось экспериментально рассчитать коэффициент .
Да конечно . нагрузка стимулируется с помощью штатной утилиты pgbench. Стандартные запросы к тестовым таблицам select, insert, update.
И поскольку нагрузка создается одновременно , не от одной сессии, точно есть одновременные операции чтения/записи. Наверное это уже больше вопрос по части Unix, не СУБД. Как друг на друга влияет чтение и запись в ram и io?
Что касается СУБД то наверняка кэш СУБД может стать узким местом при очень большом количестве операций чтения/записи. Но зто тема следующего исследования .
Меня давно интересовало - откуда взялась всем рекомендуемая цифра размера shared_buffer=25% от RAM size ?
Один раз встретил доклад на тему эксперимента по поводу размера shared_buffer, кстати в облаке помню. Но , результаты эксперимента статистически не обрабатывались , это я тоже помню.
Принципиальное преимущество в том, что такая метрика, возможно, лучше отражает физическую реальность в вашей ситуации. Всегда следует использовать наиболее близкие к реальности модели.
Согласен по каждому пункту.
Расчет будет изменен. Результаты будут опубликованы .
каким-то пользователям необходимо обеспечить быстрый отклик, а какие-то пользователи могут быть не особо важны, и оптимизация для них может быть попросту вредной.
А можно пример из жизни такой оригинальной архитектуры и бизнес требований?
А можете предоставить любые расчёты или результаты экспериментов, для обоснования следующих утверждений:
Чем выше отношение W / (R+W) - тем больше погрешность метода. При достаточно высоком отношении влияние затрат на ожидание/постановку/снятие эксклюзивных блокировок будет порядково выше, чем затрат на операции поиска/выборки.
Начиная с какой-то величины созависимости пренебрежение ей делает независимую модель практически неработоспособной.
Ну и мой любимый вопрос - производительность вы как считаете ?
производительность СУБД зависит не только от настройки (задача ДБА), но и от способа работы с ней (задача Дата Архитектора).
Что значить "зависит"?
Следующее утверждение на чем основано
вывод, который непосредственно идет из последнего абзаца - только Дата Инженер / Дата Архитектор компетентны в оптимальной работе с БД.
Если предположить, что максимальная скорость одновременных чтения/записи равна половине максимальной скорости чтения или записи по отдельности - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
Пользуясь случаем - вопрос. А какое принципиальное преимущество использование Манхэтенской метрики ? Возможны ли аномалии производительности , если использовать Евклидову метрику ?
Это ведь просто цифра, первоначально я хотел просто сумму использовать.
Но я боюсь, что в вашей СУБД, скорее всего, присутствует взаимное влияние чтения и записи.
Однако , спасибо за вопрос.
Вот так сразу даже не могу придумать экспериментальную проверку . Надо поглубже документацию почитать . И пока меня терзают смутные сомнения , что влияние имеет место .
1) Чем отличаются друг от друга N1 и N3? В описании я разницы не заметил. Возможно, вы допустили опечатку.
Да конечно , это опечатка. Сорри. N1 - количество записанных блоков в секунду, N3 - количество измененных(загрязнённых) блоков в секунду.
2) Что это за "блоки распределенной памяти", это не тот ли объем информации, который СУБД за единицу времени считывает с диска / записывает на диск?
СУБД не читает данные с диска непосредственно . Блоки читаются из распределенно области памяти. Разумеется , если блок в общей памяти не найден , он будет читаться с диска( а это задержка на дисковую операцию). Если все данные находятся в памяти , то операции с диском минимальны. В этом то и есть момент оптимизации - количество прочитанных блоков одинаково, но время выполнения одного и того же запроса разное. Причин - мегатонны.
А не будет ли логично измерять объем информации, принятый или переданный клиентам в ответ на их запросы за единицу времени?
Есть очень большая проблема с получением этих данных. Статистика СУБД не содержит информации об объеме информации переданной клиенту, только количество строк. Метрики мониторинга во первых врут, во вторых доступ к API мониторинга из СУБД , я например не знаю как реализовать.
Это именно модуль в Евклидовом пространстве = sqrt(N1^2+N2^2+N3^2)
Да именно так. Почему? Стратегического фундаментального обоснования нет. Пока не вижу причин, почему бы и не так считать.
Но есть одно очень важное уточнение. В настоящее время метрика производительности считается по другому. Не вдаваясь в глубинные подробности , если считать производительность как модуль векторы (N1, N2, N3) то возникает аномалия - берем запрос считаем производительность, добавляем индексы, запрос работает на порядки быстрее и эффективнее , но метрика снизится. А в случае если используется Index Only Scan будет равна 0 .
Сейчас метрика считается по другому. Статья в процессе подготовки.
Если предположить, что максимальная скорость одновременных чтения/записи равна максимальной скорости чтения или записи - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
А вот за это очередное спасибо. Потому, что повторюсь, никакого фундаментального обоснования использования Евклидового пространства - нет. Нужно было быстро получить цифру и перейти уже не посредственно к статистическому анализу.
В приведенных в вашем комментарии графиках слишком мало данных - трудно увидеть на глаз какие-либо определенные закономерности.
Приведенные в комментарии данные это показатели обычной производительности. Не постоянная нагрузка для benchmark. Закономерности там и не должно быть , есть корреляции с активными сессиями СУБД и ожиданиями СУБД .
А как у вас вообще определяется понятие "Производительность" и как проводится ее измерение?
За ответ на этот вопрос меня регулярно минусуют и сливают карму ;-) Но я уточню.
Ранее производительность считалась как модуль вектора ( N1 , N2 , N3 ) , где N1- количество блоков распределенной памяти записанных в секунду, где N2- количество блоков распределенной памяти прочитанных в секунду, где N3- количество блоков распределенной памяти записанных в секунду. Проще говоря это объемная скорость обработки информации СУБД . Данная метрика вполне себе работает и согласуется с реальной картиной наблюдений ( когда есть реальная авария , метрика падает , что кстати нельзя сказать о метрике "среднее время отклика") . Но , всегда есть но. Если считать метрику таким образом , можно наткнутся на аномалию - я создаю индексы, в результате запросы работают быстрее, но метрика покажет снижение . Эта аномалия решена, сейчас метрика считается по другому, пока работы в процессе анализа и экспериментов, чуть позже будет статья. Наверное когда будет готова статья о применении метода покоординатного спуска для оптимизации набора параметров СУБД. В общем сейчас метрика согласуется с реальными наблюдениями - чем эффективнее работают запросы в СУБД - тем выше метрика.
Но если видно, что данные измерений имеют тенденцию кучковаться около нескольких "центров притяжения" - иными словами, образовывать кластеры - то есть смысл эти кластеры разделить.
Да , именно так и есть. Но тут возникает очень серьезная проблема - запросов не просто много , а очень много .собирать историю и статистику по всем запросам , что бы разделять их затем по какой либо группировке - очень затратно. Я в свое время (первая статья на хабре) пытался строить историю выполнения запроса - получалось несколько мегабайт(или даже гигабайт) в минуту при средней (порядка 100 активных сессий) нагрузке. Тема еще ждет своего развития.
Чем еще мне не нравится средняя температура по больнице применимо к запросам . Допустим время отклика увеличилось , это инцидент ? Не обязательно - просто характер нагрузки изменился. Например, ввели все данные и запускают аналитику. Это вполне штатная ситуация , но она потребует время на анализ . С другой стороны, и это зафиксированный факт со скриншотами, возможна реальная авария и при этом время отклика уменьшается . Т.е. метрика "Время отклика СУБД" подвержено ошибкам первого и второго рода. Да , меня за это минусуют, но это факт. И ничего с этим не поделать. Мы давно не анализируем эту метрику.
Как правило, образованию кластеров способствуют изменения параметров наблюдаемого процесса.
Да именно. Запросы OLTP , OLAP , DWH они сильно разные. Но, пока эта тема в стадии предварительного планирования . Наверное займусь на следующий год. На текущий момент более актуально
1) Анализ бенчмарков: количественная и качественная оценка вносимых изменений в конфигурацию СУБД и инфраструктуры на производительность СУБД. Например - на сколько изменится производительность СУБД если изменить параметр на 10%, на 50% , на 150% ?
2) Оптимизация наборов конфигурационных параметров СУБД для получения максимальной производительности
Мысль про кластеры , очень интересная , большое спасибо , и наверняка будет использована , когда дойдут руки до анализа производительности отдельных SQL запросов . Спасибо.
Просто напомню как сейчас делают DBA - просто смотрят время выполнения запроса. В жизни ситуация чуть другая - в одной ситуации запрос выдал R1 строк и затратил T1 времени , в другой ситуации тот же самый запрос выдал R2 строк и затратил T2 времени. Имеется ли деградация производительности , если T2 > T1 и R2 > R1 ?
И это самый простой случай, не учитывающий влияние данного запроса на другие запросы и СУБД в целом.
“если ты гуманитарий, а в QA идти не хочется, то есть один путь – в менеджеры проектов”.
Я таких манагеров - каждый день вижу.....
Классически - подписываюсь под каждым словом.
Сорри, не могу яростно заплюсовать. Но если хоть один из , выбирающий путь в IT прочтет , задумается и решит не выбрать путь менеджера проектов - спасибо и от меня лично.
Я вообще не понимаю - как можно назначать на управляющие должности неженатых/незамужних/etc. вчерашних выпускников ускоренных курсов ? Но это сплошь и рядом и уже тренд.
Результат предсказуем - **** **** и в продакшн (с)
Мне важнее не количество просмотров, а количество полезных комментариев.
Я публикую статьи потому, что мне нужна обратная связь . Иной возможности , кроме комментариев на Хабре у меня нет.
И тут выяснилась очень интересная особенность. Тема, которой я занимаюсь имеет отношение к СУБД и математике . Размещая статьи в хабе СУБД я не получал ничего кроме флуда , пустых комментов , минусов и слива кармы. Разместив статью в хабе математика - я получил обратную связь и множество полезных комментариев и новых идей для работы.
В общем , для меня - обсуждать с коллегами DBA вопросы математики - нет особого смысла . Да и в области СУБД текущее состояние , больше похоже не на научно-инженерное сообщество, а на средневековую гильдию или цех или собрание шаманов алхимиков. Например понять почему используется именно такое значение параметра - практически невозможно . Стандартная отговорка - это рекомендация best practics. А уж результатов экспериментов вообще практически нет .
В общем
Я понимаю, что не дорабатываю.
Может вы выбрали не тот хаб ? Например , по моему опыту - стиль , польза и содержание комментариев математиков и DBA отличается принципиально . Я столько времени потерял ожидая обратной связи от DBA, даже как то обидно. А с математиками - сразу же , первый же комментарий - пища для размышлений .
P.S.
Остальные статьи обнулили рейтинг и карму.
Теме кармы и цензуре на Хабре на моей памяти лет 5-6 меняется ничего. Есть очень ненулевые шансы обнуления и минуса кармы за комментарий или статью которая не тренде толпы.
Критерий выбора значения , описанный в указанной статье - устарел . Вы первый кто обратил внимание . Спасибо.
В настоящее время критерий выбора результата изменился.
Ожидаемый результат Для определения значения производительности , которое будет принято в качестве результата , необходимо найти отрезок удовлетворяющий следующим требованиям:
Распределение значений является унимодальным
Распределение значений максимально приближено к нормальному.
Для оценки приближения распределения к нормальному используется оценка асимметрии и эксцесса. Статистический анализ результатов benchmark PostgreSQL https://habr.com/p/848134/
Скажу более , и метрика производительности СУБД считается по другому, не так как в статье на которую дается ссылка , обнаружена и исправлена очень интересная аномалия расчёта .
Если интересно - опишу в отдельной статье . В хабе "Математика".
P. S.Для коллег DBA больше не хочется тратить время , толку ноль, ни одного полезного комментария.
Поэтому не принимайте нижесказанное чересчур близко к сердцу. Но вообще, в моем случае я бы поступил так:
Вы даже не представляете, как столько времени ждал хоть какой то нормальной обратной связи и нормальных комментариев. Поэтому , еще раз - спасибо за комментарии.
1) отсеял мегавыбросы, которые на 99.99% являются браком мониторинга. Т.е. в данные как-то затесалось значение, не имеющее отношения к реальности. Если у Вас такое бывает, конечно
Возникает самый главный вопрос - а что считать выбросом ? 3сигма - не подходит, распределение на равномерное. Проблема в том, что в случае выброса это не ошибка, это стечение обстоятельств. Ну например - просто вот именно в эту минуту паразитная нагрузка на виртуальную машину резко снизилась, было выполнено очень много простых запросов , обращение к диску не было (все нашлось в кэше) в результате производительность резко скакнула. Возможно и наоборот - гипервизор начал перестраиваться, пошла дополнительная нагрузка на СХД, антивирус проснулся и загрузил СПУ, большой запрос вынужден писать блоки с диска в кэш. Т.е. это не брак, не ошибка, это стечение обстоятельств. Наверняка даже можно построить статистические зависимости именно по выбросам. Но это другая тема.
3) Разделил сигнал на "норму" и "выбросы":
Согласен.
3а) "Анализ тенденции" я бы делал по ряду вообще без выбросов. Который показывает только "норму" и ее медленные изменения. Как его сглаживать при отсутствии выбросов - не важно, все методы дадут одно и то же примерно.
Согласен - интересует тенденция , не пики. На тестовых(там мало выбросов) данных хорошо видно, анализ скользящей средняя и медиана принципиально не отличаются. Средняя визуально даже более, понятна получается.
мы идем одним фильтром и заменяем выбросы
Сорри, за повторение вопроса - как решаете какое значение считается выбросом ?
В примере- фортран-95
За это упоминание - отдельное спасибо. Помню.
А вот для скользящего на одну точку окна я предпочитаю гауссово ядро
Спасибо взял в заметки. Надо эту мысль подумать. Если , что-то выгорит и в реальности реализовано будет - Хабр себя оправдал!
Насколько это может быть применимо в Вашем случае
Предположу очень даже применимо. Чудес не бывает, всему есть причина. Тем более в данном случае имеем дело не с показаниями приборов а с цифрами. Ошибок быть не должно. Скачки и падения - не просто так. Есть причина, даже если она сразу и не известна.
Я только хотел намекнуть, что вариантов решения - великое множество, и что выбор лучшего - это отдельный квест.
Это точно. Я уж столько всего перепробовал, а сколько еще предстоит.
Точнее, я верю, что СУБД может ощутимо притормозить, если там подтянулись какие-то ресурсоемкие внутренние процессы. Но резко ускориться?!
А если посмотреть на вопрос под другому - СУБД постоянно тормозит но иногда по стечению обстоятельств внешняя нагрузка на время пропадает. В данном случае, время не такое и маленькое - 1 минута.
Ведь если запросов много, и они случайным образом поступают из многих разных источников, то согласно ЦПТ, выбросов там быть не должно?
Но есть один очень важный момент. Кроме нагрузки создаваемой на СУБД запросами есть нагрузки создаваемые внутренними процессами СУБД + нагрузка инфраструктуры. Ну например - именно в это момент отключили несколько виртуалок и утилизация СХД резко упала, потом опять включили и утилизация возросла -а в результате - сначала резкое снижение ожиданий IO потом опять рост. Ну это так примерно на пальцах , очень приближенно. А если еще вспомнить , что CPU могут менять тактовую частоту или ОС имеет не один и не два кэша, а еще и кэши CPU... Т.е. производительность СУБД обусловлена не только запросами но и очень многими внешними(неуправляемыми и случайными) факторами.
А не могли ли там еще какие-то аномалии и в инструментах сбора статистики наложиться?
Это мое очень серьезное опасение и прям таки тревога. На одну аномалию я случайно уже наткнулся - разница в округлении для numeric и double precision. Долго ошибку искал пока понял , в чем дело . А сколько еще может быть скрыто ;-(
в такой ситуации можно попытаться проанализировать именно выбросы.
Повторюсь - это очень интересная мысль. Хотя , надо еще подумать над предметной областью.
Спасибо большое за комментарии. Есть над чем подумать.
Я лично эпоху НИИ и КБ почти не застал. Сразу начал работать в СП.
Но по описываемым деталям могу сказать - с тех пор изменилось ничего. Чем крупнее компания , тем более походит на то, что описано.Иногда совпадения буквально дословные .
спектакль, который со мной был разыгран, является стандартным приемом в НИИФИ, когда нашкодившая группа начинает шуметь, агрессивно-возбужденно «нести пургу», обвинять всех подряд и оппонентов, создавать гвалт..
Вопрос по графикам из раздела "Пример из жизни". На графиках исходных данных Эксперимента 1 видно как будто 2 кривых.
Каждая точка это одно измерение производительности СУБД. Периодичность измерения 1 минута. Это пример из жизни с тестовой нагрузкой.
Реальная нагрузка выглядит чуть по другому
Пример продуктивной нагрузки 1
Пример продуктивной нагрузки 2
Пример продуктивной нагрузки 3
наилучшим подходом, на мой взгляд, было бы их сначала разделить на принадлежность к первому или второму кластеру, а потом обрабатывать по отдельности.
Как можно разделить показатели производительности СУБД ? По какому признаку ?
Может ли быть такое, что на вашу БД приходит 2 разных вида запросов
Это не может быть это именно так и есть. Кроме пользовательских операций с тестовыми таблицами SELECT , INSERT , UPDATE , на СУБД непосредственно влияют сервисные процессы autovacuum, checkpoint, etc. И это самый простой случай, пользовательская нагрузка ограничена и контролируема. Влияние процессов СУБД может быть значительным, но более менее предсказуемо . Вот с внешней нагрузкой сложнее - как и когда запустится антивирус и что там происходит на гипервизоре и СХД у DBA - информации нет .
имеет смысл при сборе исходных данных собирать не только данные по нагрузке, но и данные по поступающим видам запросов и впоследствии группировать данные измерений в соответствии с этим.
Тема еще на этапе эскизной проработки. После более менее завершения со статистическим анализом производительности СУБД и бенчмарков , займусь запросами.
Спасибо за ответ и полезную информацию.
Тема в работе, посмотрим, что получится.
Добрый вечер, возник следующий вопрос - допустим значение bgwriter_lru_maxpages (или значение другого параметра) слишком большое, возникнут ли какие либо ожидания ?
Или другими словами - возможно от определить , что настройка контрольной точки оптимальна ?
Ещё раз спасибо .
Казалось , бы вполне очевидное замечание. Но с очень далеко идущими последствиями.
Например - если назначить вес для операции записи больше чем операции чтения , метрика производительности при большем количестве записи будет меньше .
Осталось экспериментально рассчитать коэффициент .
Да конечно . нагрузка стимулируется с помощью штатной утилиты pgbench. Стандартные запросы к тестовым таблицам select, insert, update.
И поскольку нагрузка создается одновременно , не от одной сессии, точно есть одновременные операции чтения/записи. Наверное это уже больше вопрос по части Unix, не СУБД. Как друг на друга влияет чтение и запись в ram и io?
Что касается СУБД то наверняка кэш СУБД может стать узким местом при очень большом количестве операций чтения/записи. Но зто тема следующего исследования .
Меня давно интересовало - откуда взялась всем рекомендуемая цифра размера shared_buffer=25% от RAM size ?
Один раз встретил доклад на тему эксперимента по поводу размера shared_buffer, кстати в облаке помню. Но , результаты эксперимента статистически не обрабатывались , это я тоже помню.
Большое спасибо за комментарий
Согласен по каждому пункту.
Расчет будет изменен. Результаты будут опубликованы .
А можно пример из жизни такой оригинальной архитектуры и бизнес требований?
А можете предоставить любые расчёты или результаты экспериментов, для обоснования следующих утверждений:
Ну и мой любимый вопрос - производительность вы как считаете ?
Что значить "зависит"?
Следующее утверждение на чем основано
Это ваш личный вывод ?
Более подробно здесь Производительность СУБД — расчет метрики, временной анализ, параметрическая оптимизация / Хабр (habr.com)
Спасибо за комментарий.
В настоящее время производительность СУБД рассчитывается как отношение скорости выполнения операций к объемной скорости обработанных блоков.
Скорость выполнения операций(Операционная скорость) = модуль вектора ( QPS , TPS , RPS ) , где:
QPS - количество завершенных операций в секунду
TPS - количество зафиксированных транзакций в секунду
RPS - количество выданных строк в секунду
Объемная скорость = модуль вектора ( SWS , SRS , SDS , LWS , LRS , LDS , TWS , TRS ), где:
SWS - число разделяемых блоков, записанных в секунду
SRS - число разделяемых блоков, прочитанных в секунду
SDS - число разделяемых блоков, загрязнённых в секунду
LWS - число локальных блоков, записанных в секунду
LRS - число локальных блоков, прочитанных в секунду
LDS - число локальных блоков, загрязнённых в секунду
TWS - число временных блоков, записанных в секунду
TRS - число временных блоков, прочитанных в секунду
Отношение Операционной скорости к Объемной скорости и используется в качестве значения метрики CPI .
Модуль вектора , рассчитывается как модуль вектора в Евклидовом пространстве.
Есть предложение использовать " Манхэттенская метрика " , пока на этапе анализа.
Пользуясь случаем - вопрос. А какое принципиальное преимущество использование Манхэтенской метрики ? Возможны ли аномалии производительности , если использовать Евклидову метрику ?
Это ведь просто цифра, первоначально я хотел просто сумму использовать.
Однако , спасибо за вопрос.
Вот так сразу даже не могу придумать экспериментальную проверку . Надо поглубже документацию почитать . И пока меня терзают смутные сомнения , что влияние имеет место .
Да конечно , это опечатка. Сорри. N1 - количество записанных блоков в секунду, N3 - количество измененных(загрязнённых) блоков в секунду.
СУБД не читает данные с диска непосредственно . Блоки читаются из распределенно области памяти. Разумеется , если блок в общей памяти не найден , он будет читаться с диска( а это задержка на дисковую операцию). Если все данные находятся в памяти , то операции с диском минимальны. В этом то и есть момент оптимизации - количество прочитанных блоков одинаково, но время выполнения одного и того же запроса разное. Причин - мегатонны.
Есть очень большая проблема с получением этих данных. Статистика СУБД не содержит информации об объеме информации переданной клиенту, только количество строк. Метрики мониторинга во первых врут, во вторых доступ к API мониторинга из СУБД , я например не знаю как реализовать.
Да именно так. Почему? Стратегического фундаментального обоснования нет. Пока не вижу причин, почему бы и не так считать.
Но есть одно очень важное уточнение. В настоящее время метрика производительности считается по другому. Не вдаваясь в глубинные подробности , если считать производительность как модуль векторы (N1, N2, N3) то возникает аномалия - берем запрос считаем производительность, добавляем индексы, запрос работает на порядки быстрее и эффективнее , но метрика снизится. А в случае если используется Index Only Scan будет равна 0 .
Сейчас метрика считается по другому. Статья в процессе подготовки.
А вот за это очередное спасибо. Потому, что повторюсь, никакого фундаментального обоснования использования Евклидового пространства - нет. Нужно было быстро получить цифру и перейти уже не посредственно к статистическому анализу.
Теперь есть возможность - оптимизировать.
Спасибо .
Приведенные в комментарии данные это показатели обычной производительности. Не постоянная нагрузка для benchmark. Закономерности там и не должно быть , есть корреляции с активными сессиями СУБД и ожиданиями СУБД .
За ответ на этот вопрос меня регулярно минусуют и сливают карму ;-) Но я уточню.
Ранее производительность считалась как модуль вектора ( N1 , N2 , N3 ) , где N1- количество блоков распределенной памяти записанных в секунду, где N2- количество блоков распределенной памяти прочитанных в секунду, где N3- количество блоков распределенной памяти записанных в секунду. Проще говоря это объемная скорость обработки информации СУБД . Данная метрика вполне себе работает и согласуется с реальной картиной наблюдений ( когда есть реальная авария , метрика падает , что кстати нельзя сказать о метрике "среднее время отклика") . Но , всегда есть но. Если считать метрику таким образом , можно наткнутся на аномалию - я создаю индексы, в результате запросы работают быстрее, но метрика покажет снижение . Эта аномалия решена, сейчас метрика считается по другому, пока работы в процессе анализа и экспериментов, чуть позже будет статья. Наверное когда будет готова статья о применении метода покоординатного спуска для оптимизации набора параметров СУБД. В общем сейчас метрика согласуется с реальными наблюдениями - чем эффективнее работают запросы в СУБД - тем выше метрика.
Да , именно так и есть. Но тут возникает очень серьезная проблема - запросов не просто много , а очень много .собирать историю и статистику по всем запросам , что бы разделять их затем по какой либо группировке - очень затратно. Я в свое время (первая статья на хабре) пытался строить историю выполнения запроса - получалось несколько мегабайт(или даже гигабайт) в минуту при средней (порядка 100 активных сессий) нагрузке. Тема еще ждет своего развития.
Чем еще мне не нравится средняя температура по больнице применимо к запросам . Допустим время отклика увеличилось , это инцидент ? Не обязательно - просто характер нагрузки изменился. Например, ввели все данные и запускают аналитику. Это вполне штатная ситуация , но она потребует время на анализ . С другой стороны, и это зафиксированный факт со скриншотами, возможна реальная авария и при этом время отклика уменьшается . Т.е. метрика "Время отклика СУБД" подвержено ошибкам первого и второго рода. Да , меня за это минусуют, но это факт. И ничего с этим не поделать. Мы давно не анализируем эту метрику.
Да именно. Запросы OLTP , OLAP , DWH они сильно разные. Но, пока эта тема в стадии предварительного планирования . Наверное займусь на следующий год. На текущий момент более актуально
1) Анализ бенчмарков: количественная и качественная оценка вносимых изменений в конфигурацию СУБД и инфраструктуры на производительность СУБД. Например - на сколько изменится производительность СУБД если изменить параметр на 10%, на 50% , на 150% ?
2) Оптимизация наборов конфигурационных параметров СУБД для получения максимальной производительности
Мысль про кластеры , очень интересная , большое спасибо , и наверняка будет использована , когда дойдут руки до анализа производительности отдельных SQL запросов . Спасибо.
Просто напомню как сейчас делают DBA - просто смотрят время выполнения запроса. В жизни ситуация чуть другая - в одной ситуации запрос выдал R1 строк и затратил T1 времени , в другой ситуации тот же самый запрос выдал R2 строк и затратил T2 времени. Имеется ли деградация производительности , если T2 > T1 и R2 > R1 ?
И это самый простой случай, не учитывающий влияние данного запроса на другие запросы и СУБД в целом.
Я таких манагеров - каждый день вижу.....
Классически - подписываюсь под каждым словом.
Сорри, не могу яростно заплюсовать. Но если хоть один из , выбирающий путь в IT прочтет , задумается и решит не выбрать путь менеджера проектов - спасибо и от меня лично.
Я вообще не понимаю - как можно назначать на управляющие должности неженатых/незамужних/etc. вчерашних выпускников ускоренных курсов ? Но это сплошь и рядом и уже тренд.
Результат предсказуем - **** **** и в продакшн (с)
Из личного опыта.
Мне важнее не количество просмотров, а количество полезных комментариев.
Я публикую статьи потому, что мне нужна обратная связь . Иной возможности , кроме комментариев на Хабре у меня нет.
И тут выяснилась очень интересная особенность. Тема, которой я занимаюсь имеет отношение к СУБД и математике . Размещая статьи в хабе СУБД я не получал ничего кроме флуда , пустых комментов , минусов и слива кармы. Разместив статью в хабе математика - я получил обратную связь и множество полезных комментариев и новых идей для работы.
В общем , для меня - обсуждать с коллегами DBA вопросы математики - нет особого смысла . Да и в области СУБД текущее состояние , больше похоже не на научно-инженерное сообщество, а на средневековую гильдию или цех или собрание шаманов алхимиков. Например понять почему используется именно такое значение параметра - практически невозможно . Стандартная отговорка - это рекомендация best practics. А уж результатов экспериментов вообще практически нет .
В общем
Может вы выбрали не тот хаб ? Например , по моему опыту - стиль , польза и содержание комментариев математиков и DBA отличается принципиально . Я столько времени потерял ожидая обратной связи от DBA, даже как то обидно. А с математиками - сразу же , первый же комментарий - пища для размышлений .
P.S.
Теме кармы и цензуре на Хабре на моей памяти лет 5-6 меняется ничего. Есть очень ненулевые шансы обнуления и минуса кармы за комментарий или статью которая не тренде толпы.
Критерий выбора значения , описанный в указанной статье - устарел . Вы первый кто обратил внимание . Спасибо.
В настоящее время критерий выбора результата изменился.
Скажу более , и метрика производительности СУБД считается по другому, не так как в статье на которую дается ссылка , обнаружена и исправлена очень интересная аномалия расчёта .
Если интересно - опишу в отдельной статье . В хабе "Математика".
P. S.Для коллег DBA больше не хочется тратить время , толку ноль, ни одного полезного комментария.
Вы даже не представляете, как столько времени ждал хоть какой то нормальной обратной связи и нормальных комментариев. Поэтому , еще раз - спасибо за комментарии.
Возникает самый главный вопрос - а что считать выбросом ? 3сигма - не подходит, распределение на равномерное. Проблема в том, что в случае выброса это не ошибка, это стечение обстоятельств. Ну например - просто вот именно в эту минуту паразитная нагрузка на виртуальную машину резко снизилась, было выполнено очень много простых запросов , обращение к диску не было (все нашлось в кэше) в результате производительность резко скакнула. Возможно и наоборот - гипервизор начал перестраиваться, пошла дополнительная нагрузка на СХД, антивирус проснулся и загрузил СПУ, большой запрос вынужден писать блоки с диска в кэш. Т.е. это не брак, не ошибка, это стечение обстоятельств. Наверняка даже можно построить статистические зависимости именно по выбросам. Но это другая тема.
Согласен.
Согласен - интересует тенденция , не пики. На тестовых(там мало выбросов) данных хорошо видно, анализ скользящей средняя и медиана принципиально не отличаются. Средняя визуально даже более, понятна получается.
Сорри, за повторение вопроса - как решаете какое значение считается выбросом ?
За это упоминание - отдельное спасибо. Помню.
Спасибо взял в заметки. Надо эту мысль подумать. Если , что-то выгорит и в реальности реализовано будет - Хабр себя оправдал!
Предположу очень даже применимо. Чудес не бывает, всему есть причина. Тем более в данном случае имеем дело не с показаниями приборов а с цифрами. Ошибок быть не должно. Скачки и падения - не просто так. Есть причина, даже если она сразу и не известна.
Это точно. Я уж столько всего перепробовал, а сколько еще предстоит.
А если посмотреть на вопрос под другому - СУБД постоянно тормозит но иногда по стечению обстоятельств внешняя нагрузка на время пропадает. В данном случае, время не такое и маленькое - 1 минута.
Но есть один очень важный момент. Кроме нагрузки создаваемой на СУБД запросами есть нагрузки создаваемые внутренними процессами СУБД + нагрузка инфраструктуры. Ну например - именно в это момент отключили несколько виртуалок и утилизация СХД резко упала, потом опять включили и утилизация возросла -а в результате - сначала резкое снижение ожиданий IO потом опять рост. Ну это так примерно на пальцах , очень приближенно. А если еще вспомнить , что CPU могут менять тактовую частоту или ОС имеет не один и не два кэша, а еще и кэши CPU... Т.е. производительность СУБД обусловлена не только запросами но и очень многими внешними(неуправляемыми и случайными) факторами.
Это мое очень серьезное опасение и прям таки тревога. На одну аномалию я случайно уже наткнулся - разница в округлении для numeric и double precision. Долго ошибку искал пока понял , в чем дело . А сколько еще может быть скрыто ;-(
Повторюсь - это очень интересная мысль. Хотя , надо еще подумать над предметной областью.
Спасибо большое за комментарии. Есть над чем подумать.
Плюсую. Чуть выше - именно тоже самое.
Спасибо за статью.
Я лично эпоху НИИ и КБ почти не застал. Сразу начал работать в СП.
Но по описываемым деталям могу сказать - с тех пор изменилось ничего. Чем крупнее компания , тем более походит на то, что описано.Иногда совпадения буквально дословные .
Может быть дело не во времени, а в людях ?
Каждая точка это одно измерение производительности СУБД. Периодичность измерения 1 минута. Это пример из жизни с тестовой нагрузкой.
Реальная нагрузка выглядит чуть по другому
Как можно разделить показатели производительности СУБД ? По какому признаку ?
Это не может быть это именно так и есть. Кроме пользовательских операций с тестовыми таблицами SELECT , INSERT , UPDATE , на СУБД непосредственно влияют сервисные процессы autovacuum, checkpoint, etc. И это самый простой случай, пользовательская нагрузка ограничена и контролируема. Влияние процессов СУБД может быть значительным, но более менее предсказуемо . Вот с внешней нагрузкой сложнее - как и когда запустится антивирус и что там происходит на гипервизоре и СХД у DBA - информации нет .
Мониторинг производительности отдельных запросов к СУБД это следующая очень большая тема будет. Пока только наброски Мониторинг производительности отдельного SQL запроса / Хабр (habr.com)
Тема еще на этапе эскизной проработки. После более менее завершения со статистическим анализом производительности СУБД и бенчмарков , займусь запросами.