PG_EXPECTO v.7 + DeepSeek : Статистический анализ инцидента производительности СУБД PostgreSQL - интенсивная запись и дефицит RAM.
Представленный документ содержит результаты всестороннего анализа инцидента снижения производительности СУБД PostgreSQL, произошедшего 26 февраля 2026 года. Исследование построено на сравнении двух часовых интервалов: тестового (период штатной работы) и периода самого инцидента. С помощью нейросетевого анализа были обработаны статистические данные по ожиданиям СУБД, метрикам инфраструктуры (vmstat) и профилям запросов, что позволило не только зафиксировать отклонения, но и выявить глубинные корреляционные связи между ними. В отчете последовательно раскрывается картина деградации: от экспресс-оценки ключевых различий до детального разбора по каждому компоненту системы — от загрузки CPU и состояния памяти до анализа очередей и типов блокировок. Особое внимание уделено изменению структуры ожиданий и появлению нового тяжелого запроса, что в совокупности с критическим дефицитом оперативной памяти привело к перегрузке всех ресурсов. Материал структурирован так, чтобы дать четкое понимание первопричин сбоя и предоставить обоснованную основу для принятия мер по стабилизации работы базы данных. https://dzen.ru/a/aaBoYVDyKj0FBx4l
· 27.02
Интеграция с deepseek тут под вопросом. В том плане, что ни одна крупная компания из соображений ИБ не допустит, чтоб метрики проекта анализировались вне контура компании.
Я бы посмотрел в сторону n8n. Который можно локально в контуре компании развернуть и обучить.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 27.02
1) по поводу метрик - какие риски , по вашему ? Это ведь просто цифры . ну мне просто любопытно . 2) локально в контуре разворачивать это не имеет никакого смысла. Во-первых - ресурсы которые никогда не окупятся. Во-вторых локально в принципе невозможно собрать массив данных для обучения. Т.е. получится проект ради распила бюджета с нулевой практической пользой. В этом то и преимущество DeepSeek перед GigaChat и YandexGPT - у китайцев ОГРОМНЫЙ МАССИВ ДАННЫХ для обучения и анализа. Поэтому DeepSeek можно использовать для работы а GigaChat и YandexGPT это игрушки
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.02
Статистика производительности никакой ценности не несет для злоумышленников. Но вряд ли Вы захотите спорить с отделом ИБ, как только прилетит предупреждение или даже взыскание в личное дело, за разглашение корпоративной информации или персональных данных. Это такая тонкая грань, вряд ли кто-то захочет подставляться так, устанавливая этот инструмент. Вы сами работали в ГринАтом, и знаете, как в таких компаниях все строго.
В pg_expecto используется расширение pg_wait_sampling - через него можно увидеть запросы, которые стоят в ожидании.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.02
1)По поводу споров с ИБ , мне просто любопытно - лично вы сколько раз общались с ибшниками ? Я общался. это к вопросу - не так страшен черт. Т.е. как работает иб я знаю на личном опыте. 2) по поводу pg_wait_sampling и увидеть запросы - вы как себе этот процесс представляете ? Ну вот практически ? Учитывая , что всё, что получает нейросеть для анализа это статистические данные и названия метрик. Теперь даже временные ряды нет необходимости передавать. Статистическая обработка делается в pg_expecto.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.02
Да, я тоже общался с ИБ. Там манипулировать информацией умеют.
В общем, это я все к тому, что есть аналог. У Postgrespro Enterprise есть инструмент. Mamonsu. Работает как zabbix agent, но есть еще и функционал отчётов и формирование более оптимального postgresql.conf.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.02
Насчёт манипуляций - ну, я тоже не вчера в IT сфере . Mamonsu это вообще другое. Мониторинг и сбор метрик никакого отношения к анализу производительности не имеет. Это просто сырые данные. Выводы из них без обработки можно делать любые. Про оптимальный "postgresql.conf" - а какой критерий является метрикой оптимальности ?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.02
Когда кэш промахи составляют менее 10%.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.02
Зто не критерий оптимальности. Для OLAP нагрузки hit ratio 50-60% это норма
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён