Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме. Иначе получается "к пуговицам претензии есть?"
Но это определяется разделением обязанностей в организации. Например, ответственным за тупящий запрос можно назначить написавшего его разработчика , которого DBA научит, как его переписать эффективнее. Можно - DBA, заставляя его самостоятельно придумывать подходящие для запросов индексы. А можно - и "железячников", заставляя выделять больше аппаратных ресурсов для БД.
Согласен, что снапшот-модель интервальных отчетов мало полезна. Но и анализ конкретных фактов с помощью матстата выглядит как-то не слишком оптимально.
Статью читал, но как применить к реальным условиям использования - не придумал. На мой взгляд, оно может быть полезно, если "везде все хорошо и вдруг где-то становится плохо". У нас же обычно можно взять любой хост и какую-нибудь неоптимальность да найти, а раз нашел - стоит устранить.
Хранение лога - второстепенная для нас задача, а основная - заранее известные выборки.
Мы пробовали использовать колоночные хранилища, например, citus. Получилось, что четко зная целевую выборку, можно написать запрос, работающий в 3-4 раза чем на citus.
Операционка. Полностью одновременно писать в один и тот же блок данных она все равно не позволит. В достаточно большой файл - да, в атомарный его блок - нет.
Если "нормальный" == "клиентоориентированный", то не далее как сегодня, загнав машину на замену масла, попросил заодно проверить ручник. И таки да, поменяли колодки, суппорт и подтянули ручник без вопросов.
Ведь меня как пользователя машины интересует ее полная исправность, а не то, что Вася - электрик, Петя - механик, и как они делят обязанности на современных электромобилях.
К сожалению (или к счастью), описываемые мной решения и методики - это наш собственный путь по реальным граблям в том числе и на продах - то есть никакого теоретизирования, сугубо практические выкладки, накопленные за последние 10-15 лет.
Например, вот тут я приводил примеры анализа ситуаций, которые требуют от DBA все-таки иметь кругозор и за пределами самой DB.
Поэтому взглянуть на принципиально другую методику будет весьма любопытно.
Если речь про DataFile* события ожидания, то проще говорить и о них как об ожидании доступа к заблокированному ресурсу. Не зря они в pg_locks отражаются.
определение производительности СУБД это среднее время отклика СУБД
Да, только лучше использовать не среднее, а процентили. А вот эффективность достижения одной и той же производительности может быть разной относительно использованных ресурсов.
На этом принципе реализована параллелизация выполнения в PG. Очевидно, что распределение работы по воркерам требует больше ресурсов, но дает меньшее время выполнения.
Открываем инцидент ?
Безусловно. Но не факт, что на работу СУБД. Это может быть ошибкой условия, сформированного разработчиком. В любом случае требует исследования.
примерно описать сценарий действий
Определяем проблемный хост. На нем находим подходящий шаблон запроса в конкретном методе, дальше по времени/хитмапу находим конкретный проблемный план.
Тут есть в докладе примерная логика как и почему мы пришли к таким моделям.
Если мы берем buffers.read и соотносим с io.read, то при достаточных величинах можем судить о скорости СХД "в моменте". И если эти значения каждый момент маловаты, то можем судить и о недостаточной пропускной способности дисковой подсистемы.
Понятно, что если на СХД max=10Kops положим нагрузку 15Kops, то увидим замедление каких-то из операций. Но это как раз и будет сигналом о недостаточной производительности.
По вашему производительность запроса это время выполнения запроса?
Производительность - это именно про время, а вот эффективность может определяться и объемом buffers, и их распределением по hit/read, и скоростью обмена с СХД, и размером возвращаемого resultset, которые прямо или косвенно влияют на это самое время.
Классический вопрос - если запрос выполняется дольше и возвращает больше строк - это деградация или нет?
Зачем сравнивать сладкое и теплое? Давайте лучше сравнивать в рамках одного критерия.
Если запрос хронически возвращает 1K записей, но внезапно возвращает 1M размером на несколько десятков MB - это может и не быть деградацией, но крайне подозрительно само по себе.
Если выполнялся по 10мс, а внезапно стало 1000мс - тоже подозрительно.
И далее - вы представляете размер лога при включённом auto_explain?
Есть реальные кейсы из промышленной эксплуатации ИС ?
У нас сейчас на мониторинге с включенным auto_explain ~3K инстансов PostgreSQL. Размер логов порядка 16TB за пару месяцев, дольше не храним.
Вот тут я рассказывал, как мы их собираем и храним.
auto_explain + track_io_timing + сбор и анализ всех планов = можно построить heatmap распределения времени выполнения запросов и наглядно отследить деградацию.
По крайней мере, "проблема в СХД" определяется на раз по I/O Timings.
Объём информации, сохраняемой в pg_statistic командой ANALYZE, в частности максимальное число записей в массивах most_common_vals (самые популярные значения) и histogram_bounds (границы гистограмм) для каждого столбца, можно ограничить на уровне столбцов с помощью команды ALTER TABLE SET STATISTICS или глобально, установив параметр конфигурации default_statistics_target. В настоящее время ограничение по умолчанию равно 100 записям. Увеличивая этот предел, можно увеличить точность оценок планировщика, особенно для столбцов с нерегулярным распределением данных, ценой большего объёма pg_statistic и, возможно, увеличения времени расчёта этой статистики. И напротив, для столбцов с простым распределением данных может быть достаточно меньшего предела.
Понятно, что речь и в документации идет про 100 записей значений гистограммы, а не 100 исходных. Для начинающего разработчика, на мой взгляд, и про коэффициент 300, и про увеличение времени анализа - избыточно. На эти грабли он наступит еще ой как нескоро.
Там были еще курсы по разработке бизнес-логики на python, интерфейса на JS и управлению сервисами, но они слишком сильно "заточены" на нашу внутреннюю инфраструктуру, поэтому вряд ли будут публиковаться. Возможно, их следующие версии.
Если в этой системе inn является уникальным ключом, то зачем в phone/email хранятся какие-то jsonb-объекты? Простого массива inn'ов разве недостаточно? Тогда они и искались бы эффективнее исходно.
При сравнении производительности запросов неплохо бы приводить планы, иначе может оказаться, что все "тормоза" первичного варианта вызваны исключительно стартовой незакэшированностью данных (shared read).
Какая уж тут магия? Все вполне объяснимо: gist достаточно быстро "схлапывается" до нужного прямоугольника, где находятся только искомые точки, а вот btree, фактически, для каждого подходящего значения dt делает вложенный поиск интервала по sum, что явно не быстро, поскольку линейно растет с количеством уникальных подходящих значений dt в интервале.
То есть нашли мы, например, значение dt = '2023-12-15', полезли искать внутри по sum - там ничего подходящего, а время уже потрачено.
Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме. Иначе получается "к пуговицам претензии есть?"
Но это определяется разделением обязанностей в организации. Например, ответственным за тупящий запрос можно назначить написавшего его разработчика , которого DBA научит, как его переписать эффективнее. Можно - DBA, заставляя его самостоятельно придумывать подходящие для запросов индексы. А можно - и "железячников", заставляя выделять больше аппаратных ресурсов для БД.
Согласен, что снапшот-модель интервальных отчетов мало полезна. Но и анализ конкретных фактов с помощью матстата выглядит как-то не слишком оптимально.
Статью читал, но как применить к реальным условиям использования - не придумал. На мой взгляд, оно может быть полезно, если "везде все хорошо и вдруг где-то становится плохо". У нас же обычно можно взять любой хост и какую-нибудь неоптимальность да найти, а раз нашел - стоит устранить.
Хранение лога - второстепенная для нас задача, а основная - заранее известные выборки.
Мы пробовали использовать колоночные хранилища, например, citus. Получилось, что четко зная целевую выборку, можно написать запрос, работающий в 3-4 раза чем на citus.
Операционка. Полностью одновременно писать в один и тот же блок данных она все равно не позволит. В достаточно большой файл - да, в атомарный его блок - нет.
Если "нормальный" == "клиентоориентированный", то не далее как сегодня, загнав машину на замену масла, попросил заодно проверить ручник. И таки да, поменяли колодки, суппорт и подтянули ручник без вопросов.
Ведь меня как пользователя машины интересует ее полная исправность, а не то, что Вася - электрик, Петя - механик, и как они делят обязанности на современных электромобилях.
К сожалению (или к счастью), описываемые мной решения и методики - это наш собственный путь по реальным граблям в том числе и на продах - то есть никакого теоретизирования, сугубо практические выкладки, накопленные за последние 10-15 лет.
Например, вот тут я приводил примеры анализа ситуаций, которые требуют от DBA все-таки иметь кругозор и за пределами самой DB.
Поэтому взглянуть на принципиально другую методику будет весьма любопытно.
СУБД использует СХД, поэтому причиной проблем первой могут быть проблемы второй. А могут и не быть. А может быть и наоборот.
Если у меня машина не едет нормально, то виноват некачественный бензин, проблемы с двигателем или я передачу не переключил?..
Если речь про DataFile* события ожидания, то проще говорить и о них как об ожидании доступа к заблокированному ресурсу. Не зря они в pg_locks отражаются.
Да, только лучше использовать не среднее, а процентили. А вот эффективность достижения одной и той же производительности может быть разной относительно использованных ресурсов.
На этом принципе реализована параллелизация выполнения в PG. Очевидно, что распределение работы по воркерам требует больше ресурсов, но дает меньшее время выполнения.
Безусловно. Но не факт, что на работу СУБД. Это может быть ошибкой условия, сформированного разработчиком. В любом случае требует исследования.
Определяем проблемный хост. На нем находим подходящий шаблон запроса в конкретном методе, дальше по времени/хитмапу находим конкретный проблемный план.
Тут есть в докладе примерная логика как и почему мы пришли к таким моделям.
Если мы берем buffers.read и соотносим с io.read, то при достаточных величинах можем судить о скорости СХД "в моменте". И если эти значения каждый момент маловаты, то можем судить и о недостаточной пропускной способности дисковой подсистемы.
Понятно, что если на СХД max=10Kops положим нагрузку 15Kops, то увидим замедление каких-то из операций. Но это как раз и будет сигналом о недостаточной производительности.
Ожидания и перехватываем из лога как следствие возникновения длительной блокировки.
Производительность - это именно про время, а вот эффективность может определяться и объемом buffers, и их распределением по hit/read, и скоростью обмена с СХД, и размером возвращаемого resultset, которые прямо или косвенно влияют на это самое время.
Можно вот типа таких картинок наблюдать по ходу дня.
Зачем сравнивать сладкое и теплое? Давайте лучше сравнивать в рамках одного критерия.
Если запрос хронически возвращает 1K записей, но внезапно возвращает 1M размером на несколько десятков MB - это может и не быть деградацией, но крайне подозрительно само по себе.
Если выполнялся по 10мс, а внезапно стало 1000мс - тоже подозрительно.
У нас сейчас на мониторинге с включенным auto_explain ~3K инстансов PostgreSQL. Размер логов порядка 16TB за пару месяцев, дольше не храним.
Вот тут я рассказывал, как мы их собираем и храним.
auto_explain + track_io_timing + сбор и анализ всех планов = можно построить heatmap распределения времени выполнения запросов и наглядно отследить деградацию.
По крайней мере, "проблема в СХД" определяется на раз по I/O Timings.
Способ любопытный. Правда, опирается на отсутствие \n в исходной строке и ; в заменах.
Понятно, что речь и в документации идет про 100 записей значений гистограммы, а не 100 исходных. Для начинающего разработчика, на мой взгляд, и про коэффициент 300, и про увеличение времени анализа - избыточно. На эти грабли он наступит еще ой как нескоро.
Там были еще курсы по разработке бизнес-логики на python, интерфейса на JS и управлению сервисами, но они слишком сильно "заточены" на нашу внутреннюю инфраструктуру, поэтому вряд ли будут публиковаться. Возможно, их следующие версии.
На схеме нарисовано, что ИНН - это PK в company. Где тут про ОГРН?
Ну, и в первом варианте jsonb-объект с единственным ключом inn ищется в phone/email в массиве... очевидно, состоящем из объектов такой же структуры?
Если в этой системе inn является уникальным ключом, то зачем в phone/email хранятся какие-то jsonb-объекты? Простого массива inn'ов разве недостаточно? Тогда они и искались бы эффективнее исходно.
При сравнении производительности запросов неплохо бы приводить планы, иначе может оказаться, что все "тормоза" первичного варианта вызваны исключительно стартовой незакэшированностью данных (
shared read).Какая уж тут магия? Все вполне объяснимо:
gistдостаточно быстро "схлапывается" до нужного прямоугольника, где находятся только искомые точки, а вотbtree, фактически, для каждого подходящего значенияdtделает вложенный поиск интервала поsum, что явно не быстро, поскольку линейно растет с количеством уникальных подходящих значенийdtв интервале.То есть нашли мы, например, значение
dt = '2023-12-15', полезли искать внутри поsum- там ничего подходящего, а время уже потрачено.