Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 22
Все диагностические запросы из статьи правильные. Но это как сдавать кровь каждые 30 минут вместо того, чтобы поставить нормальный autovacuum. В 9 из 10 PostgreSQL-кризисов в корне сидит autovacuum_vacuum_cost_delay со значением по умолчанию и база с write-heavy нагрузкой.
А можно подробнее пояснить как правильно настроить autovacuum_vacuum_cost_delay? Если у вас была практика работы с нагруженными системами поделительсь опытом. И еще там кажетя нужно крутить autovacuum_vacuum_cost_limit, а не только один autovacuum_vacuum_cost_delay.
Ага, в одиночку cost_delay крутить смысла мало, вы правы, это пара. Грубо говря: throughput ≈ cost_limit / cost_delay, vacuum копит стоимость и засыпает на delay, когда упрётся в limit. Так что ниже 2 мс задержку я не трогаю (в ноль вообще нельзя диск ляжет), а поднимаю cost_limit: дефолтные 200 для SSD смешные, ставлю 1000–3000.
Только не наступите на грабли: cost_limit делится между воркерами. Накинуть max_workers, не подняв лимит, каждый станет медленнее, а не быстрее. И честно, для больших горячих таблиц сильнее всего бьёт не cost-тюнинг, а scale_factor пер-таблично, с 0.2 до 0.02–0.05. Cost заставляет vacuum работать быстрее, scale_factor - приходить раньше. И поставьте log_autovacuum_min_duration = 0, иначе крутите вслепую.
Так и есть, не спорю. Только про дефолтный cost_delay оговорюсь - это боль до 11-й версии, там 20 мс. С 12-й он уже 2 мс, с 14-й и page_miss опустили с 10 до 2, так что из коробки autovacuum давно не такой зажатый. У меня в корне кризиса на свежих версиях чаще не он, а scale_factor 0.2 на здоровенной таблице (vacuum приходит, когда дохлых строк уже миллионы) и cost_limit 200, который вообще из 2004 года. Ну и любимое, это висящая транзакция держит xmin, и тогда autovacuum хоть как разгоняй, мёртвые строки убрать не дадут.
Одним cost_delay сыт не будешь, там надо крутить cost_limit и воркеры в жесткой связке, иначе он просто будет быстрее упираться в лимит и так же спать большую часть времени
Нашёл пару моментов для себя. Спасибо!
Скажите, а дебаг в ide99 планируется? Особенно интересует трассировка параллельных вызовов, сейчас приходится в двух браузерах два pgadmin запускать — и это, мягко говоря, не очень удобно.
Дебаг в планах есть. Трассировку параллельных вызовов отмечу отдельно - два pgadmin в двух браузерах боль знакомая, так что кейс понятный и нужный. Точных сроков пока не назову, но в бэклоге уже лежит. Как будет время, опишите пж свой сценарий чуть подробнее, что именно хотите видеть в трассировке, поможете с приоритетом.
Спасибо!
Кейс вроде стандартный — проверяю гипотезу о race condition в сложной функции. Дебагом иду пошагово в двух копиях и гляжу, что получает каждая на свои запросы. Step over, step into, set breakpoint, смотреть содержимое локальных переменных и коллекций. Если ещё будут и условные брейкпоинты, возможность делать селекты в контексте и редактировать переменные из GUI — вообще шикарно. Но пока и базовой функциональности было бы достаточно.
> ide99.ru
> Rust
> Cargo сборка
Нет, спасибо.
LOL. При соединении ваша IDE упала, отчёт о падении тоже не смогла отправить: {“timestamp”:“2026-05-31T08:48:41.235042Z”,“level”:“WARN”,“fields”:{“message”:“admin_telemetry: all endpoints failed”,“error”:“error sending request for url (http://89.169.150.184/telemetry/v1/events)”,“event”:“ide.heartbeat”}}
0/10
Спасибо за репорт, без иронии - краш при коннекте это серьёзно. Заведите issue на гитхабе (или киньте сюда): ОС, как подключались (хост/порт, ssl), что в логе перед падением. Телеметрия у вас как раз не ушла, так что сам я этот краш не увижу, для диагностики нужны детали. И да, телеметрию можно выключить, если смущает.
Зашел почитать про магические скрипты, а в конце предсказуемо продают очередную десктопную тулзу. Скрипты-то базовые, их любой нормальный дба наизусть помнит
а как в браузере БД, тот что справа, увидеть больше объектов БД, функции, например, а не только таблицы и вью?
Они там есть, просто сгруппированы внутри схемы, а не лежат в общем списке. Раскройте узел схемы (например, public) под Tables и Views будут отдельные группы Functions, Types, Sequences, Materialized Views. То есть путь такой: Schemas → public → Functions.
Если групп не видно - скорее всего дерево не обновилось после подключения, нажмите ⌘+R (или ↻ в шапке панели). Ещё момент: видно только то, на что у вашей роли есть права, так что функции в схеме, к которой нет доступа, не покажутся.
И лайфхак: в строке поиска над деревом префикс f: фильтрует только функции - f:jsonb_* найдёт всё, что начинается с jsonb_. Удобнее, чем листать.
https://ide99.ru/docs/schema/schema-browser/
Установлено на Astra Linux 1.8 из deb-пакета. Я подключаюсь под postgres.
База на PostgreSQL 9.6
После подключения ошибка - Unhandled rejection (стек не захвачен). Но к БД я всё-таки подключаюсь. Работает та самая станица с проверкой здоровья. В браузере БД только таблицы и вью.
А из Dbeaver всё видно.
спасибо — по вашему отчёту нашлись и поправлены сразу две вещи, обе в 1.0.7:
«Unhandled rejection» при подключении. На PostgreSQL 9.6 часть запросов к системному каталогу лезла в колонки, которых в 9.6 ещё нет (
prokind,pg_sequencesи пр.) — отсюда необработанная ошибка. Сделали совместимые версии запросов.«В браузере БД только таблицы и вью». Та же причина: функции, процедуры и последовательности не подгружались из-за тех же запросов. Теперь на 9.6 они видны, как и в DBeaver.
Обновитесь до 1.0.7 (deb уже там). Если на 9.6 где-то ещё всплывёт странность — приложите, пожалуйста, свежий ide99.log.* из папки logs/ рядом с данными приложения: мы добавили нормальные файловые логи, по ним причина видна сразу.
Этих проблем нет в 1.0.7. Всё отображается. Отличная работа! Буду следить за вашей разработкой.
Но так как инструмент для админов, то редактирование, подсветка синтаксиса, автокомплит PL/pgSQL и прочее для разработки не планируется?
Спасибо! И сразу поправлю посыл: ide99 не только для админов — для разработки тоже (наверное даже для разработки в первую очередь).
Всё, что вы перечислили, уже есть: — SQL-редактор (Monaco): правка, мульти-курсор, форматирование; — подсветка синтаксиса PostgreSQL и PL/pgSQL; — автокомплит — таблицы, колонки, CTE, функции, JSONB-пути, плюс сниппеты.
Из PL/pgSQL пока не хватает автокомплита локальных переменных и параметров внутри тела функции (DECLARE … BEGIN) — это в планах. Всё остальное для разработки на месте уже сейчас.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваш PostgreSQL болеет молча. Десяток запросов, чтобы это увидеть