29 сентября 2026 года Postgres Professional выпустила PPEM 2.10. Новый Healthcheck Advisor ищет пять типов проблем: длительные транзакции, взаимоблокировки, задержки репликации, ошибки контрольных сумм и деградацию autovacuum. Пять — результат подсчёта функций из анонса компании.
Если PPEM уже собирает телеметрию вашей СУБД, версию 2.10 стоит допустить к пилоту. Сразу обновлять рабочий контур не советуем. Опубликованные материалы не раскрывают совместимость с версиями Postgres Pro, требования к ресурсам и поведение анализатора под нагрузкой 1С.
Healthcheck Advisor может сократить путь от жалобы пользователя до первой гипотезы. Но он видит состояние СУБД, а не причину задержки конкретного документа 1С. Это инструмент для начала диагностики, а не готовый диагноз.
Advisor превращает телеметрию в список гипотез
Раньше администратору приходилось самому выбирать графики и искать отклонения. Healthcheck Advisor просматривает телеметрию по расписанию или по ручному запуску. Такой порядок описан в анонсе Postgres Professional.
Найденные события анализатор делит на четыре уровня: Critical, High, Medium и Low. Затем PPEM формирует рекомендации по устранению отклонений. Сведений об автоматическом применении этих рекомендаций в опубликованном описании нет.
Это разумная граница. Длительная транзакция может быть следствием зависшего фонового задания, ручного запроса или ошибки приложения. Менять параметры PostgreSQL только по карточке Advisor нельзя: сначала нужно подтвердить гипотезу штатными средствами СУБД.
| Что нашёл Advisor | Как PPEM показывает приоритет | Что проверить до изменений |
|---|---|---|
| Длительная транзакция | Один из уровней Critical, High, Medium или Low | Возраст транзакции, состояние сеанса, текст запроса и владельца подключения |
| Взаимоблокировка | Один из четырёх уровней критичности | Какие процессы конфликтовали, какие объекты они удерживали и повторяется ли событие |
| Задержка репликации | Один из четырёх уровней критичности | Состояние реплики, очередь WAL, сеть и доступное место на диске |
| Сбой контрольной суммы | Один из четырёх уровней критичности | Журнал PostgreSQL, состояние накопителей и наличие проверенной резервной копии |
| Деградация autovacuum | Один из четырёх уровней критичности | Статистику таблиц, накопление мёртвых строк, блокировки и настройки autovacuum |
Postgres Professional не публикует в анонсе правила назначения каждого уровня. Поэтому в пилоте нужно проверить не только обнаружение события, но и полезность выбранного приоритета.
Таблица не расшифровывает внутренние коды PPEM и не назначает способы ремонта. В третьем столбце перечислены проверки администратора перед вмешательством в рабочую СУБД.
Для задержки в 1С одного анализа PostgreSQL мало
Пользователь сообщает: документ проводится медленно. Advisor в то же время показывает длительную транзакцию. Совпадение по времени ещё не доказывает связь между этими событиями.
В описании PPEM 2.10 нет функции, которая связывает найденное отклонение с документом, сеансом или рабочим процессом сервера 1С. Анализатор работает с телеметрией СУБД. Границу его данных нужно учитывать при каждом разборе задержки.
Связь придётся достраивать по другим данным. PPEM 2.9 уже умеет вести администратора от активного сеанса к SQL-статистике по query_id. Этот маршрут описан в материале про поиск SQL-запроса активного сеанса средствами PPEM 2.9.
Даже найденный запрос не всегда объясняет задержку. Причина может находиться на хосте СУБД, сервере приложений или в Linux. Для такой проверки нужен сквозной просмотр нагрузки Linux, PostgreSQL и 1С, а не одна карточка Advisor.
Из этого следует критерий пилота: событие должно вести к проверяемой гипотезе. Если администратор видит предупреждение, находит соответствующий запрос и подтверждает причину штатной статистикой PostgreSQL, функция приносит пользу. Если связь обрывается на общей рекомендации, обновление не сокращает диагностику настолько, как обещает анонс.
Внешнее хранилище ASH разгружает управляющий сервер
Второе заметное изменение PPEM 2.10 касается Active Session History, или ASH. Это история активности сеансов, по которой администратор восстанавливает картину нагрузки за прошедший период.
По сообщению Postgres Professional, PPEM 2.10 умеет переносить историю сеансов во внешние базы. Компания связывает такой перенос со снижением нагрузки и расхода диска на управляющем сервере. Новые хранилища и параметры подключений настраиваются через веб-интерфейс.
Эта функция нужна не каждому контуру. Если история занимает мало места и не мешает работе PPEM, отдельная база добавит ещё одно подключение, права доступа и резервное копирование. Польза появляется, когда репозиторий растёт или управляющий сервер уже упирается в хранение телеметрии.
В анонсе нет порогового объёма ASH, после которого нужно выносить данные. Нет и требований к внешней базе. Решение придётся принимать по динамике собственного репозитория: сколько места занимает история, как быстро она растёт и влияет ли обслуживание на управляющий сервер.
Остальные функции закрывают отдельные сценарии эксплуатации
PPEM 2.10 меняет не только Advisor и хранение ASH. Postgres Professional также заявила настройку дашборда, топологию отказоустойчивого кластера, новые графики WAL и параметры восстановления.
Эти функции не дают общей причины для обновления. Каждая отвечает на отдельную задачу. Проверять их нужно только там, где такая задача уже возникла.
| Изменение PPEM 2.10 | Какую работу упрощает | Что проверить в пилоте |
|---|---|---|
| Внешнее хранилище ASH | Выносит историю активных сеансов из репозитория управляющего сервера | Подключение, запись новых данных, доступ к старой истории и поведение при недоступности хранилища |
| Сохранение компоновки дашборда | Оставляет выбранные таблицы, счётчики и графики между сессиями | Сохраняется ли набор виджетов после выхода и повторного входа |
| Графическая топология отказоустойчивого кластера | Показывает состав кластера одной схемой | Совпадает ли схема с фактическими ролями узлов |
| Пресеты WAL Usage и WAL Archiving | Добавляют готовые представления для контроля WAL | Хватает ли данных для проверки архивации и роста WAL в вашем контуре |
Лимит Rule execution timeout, sec | Ограничивает время работы правил обслуживания репозитория | Как PPEM сообщает о прерванном правиле и можно ли отличить тайм-аут от ошибки |
| Параметры восстановления | Передают конфигурацию, пресет настроек и имя службы systemd | Применяются ли нужные значения на тестовом восстановлении |
Для небольшой компании главная причина испытать PPEM 2.10 — Healthcheck Advisor. Остальные изменения окупают пилот лишь при большом архиве ASH, отказоустойчивом кластере или регулярной работе с восстановлением.
Postgres Professional также сообщила об оптимизации обработки больших массивов объектов и пересмотре норм сайзинга. Самих норм в переданных материалах нет. По этой формулировке нельзя пересчитывать процессоры, память или диски для PPEM.
В релизе исправлен набор уязвимостей CVE и обновлён системный стек Go до версии 1.27. Анонс не перечисляет CVE и не описывает их влияние на конкретную установку. Планировать срочное обновление только по общей фразе о безопасности рано: сначала нужен список исправлений и проверка применимости к вашей версии.
Что должен доказать пилот
Пилот лучше строить вокруг одного рабочего сценария. Возьмите период, когда пользователи 1С уже замечали задержки, либо воспроизведите известную нагрузку на тестовой базе. PPEM должен собрать достаточно телеметрии для повторяемой проверки.
Не начинайте с переноса всех данных и настройки каждого нового виджета. Сначала проверьте основное обещание релиза: Advisor находит заявленные типы отклонений и помогает перейти к подтверждаемой причине.
Подготовьте отдельный контур
Установите PPEM 2.10 отдельно от рабочего экземпляра. Подключите тестовую СУБД или копию потока телеметрии, если ваша архитектура допускает такой вариант.
Сохраните сведения о текущей версии PPEM, подключениях, регламентах и объёме репозитория. Анонс Postgres Professional не содержит порядка обновления. Значит, возврат к прежней версии нужно продумать до начала испытаний.
На этом же этапе проверьте перечень поддерживаемых версий СУБД в документации к вашему дистрибутиву. В собранных материалах такого перечня нет. Совместимость нельзя выводить из одного факта выпуска PPEM 2.10.
Запустите Advisor двумя способами
Сначала выполните проверку вручную. Так проще связать время запуска, собранную телеметрию и результат. Затем настройте расписание и дождитесь автоматической проверки.
Postgres Professional заявляет оба режима. Пилот должен подтвердить их в вашем контуре, включая сохранение результатов и уведомление администратора.
Зафиксируйте, какие из пяти типов отклонений Advisor увидел. Не пытайтесь специально вызвать сбой контрольной суммы на рабочей базе. Для испытания подходят уже наблюдавшиеся события, тестовая нагрузка и безопасно воспроизводимые блокировки.
Проверьте приоритет и рекомендацию
Четыре уровня критичности полезны только тогда, когда помогают выбрать порядок работы. Сравните уровень Advisor с фактическим влиянием события на пользователей и состояние СУБД.
Рекомендацию проверяйте отдельно. Найдите подтверждение в журналах PostgreSQL, статистических представлениях или метриках хоста. Не меняйте настройки только потому, что PPEM показал уровень Critical.
Запишите результат коротко: событие, уровень, рекомендация, подтверждающие данные и принятое действие. После нескольких запусков станет видно, сокращает ли Advisor поиск причины или лишь добавляет ещё один список предупреждений.
Испытайте внешнее хранилище ASH
Зарегистрируйте тестовое хранилище через веб-интерфейс и назначьте его целевой базой. Убедитесь, что новые записи попадают туда, а PPEM читает историю после повторного входа.
Отдельно проверьте отказ внешней базы. Опубликованные материалы не описывают поведение PPEM при потере соединения. Для рабочего внедрения нужно знать, копятся ли данные локально, теряются или записываются после восстановления связи.
Сравнивать производительность по одному короткому запуску бессмысленно. Для решения достаточно проверить корректность записи, чтения и восстановления соединения. Оценку нагрузки проводите на своём обычном периоде хранения.
Сохраните рабочую компоновку
Настройте дашборд под ежедневную проверку: оставьте нужные таблицы, счётчики и графики. Выйдите из PPEM и откройте страницу экземпляра снова.
Postgres Professional заявляет сохранение компоновки между сессиями. Если расположение сбросилось, зафиксируйте браузер, роль пользователя и порядок действий. Это даст воспроизводимое замечание, а не впечатление от интерфейса.
Чего анонс не подтверждает
PPEM 2.10 нельзя оценивать как готовое средство диагностики 1С только по перечню функций. В опубликованных материалах нет результатов испытаний на сервере 1С, описания тестовой нагрузки и сравнения времени поиска причины до обновления и после него.
Нет данных и для расчёта инфраструктуры. Анонс не называет потребление процессора, памяти, диска и сети самим Advisor. Поэтому статья не назначает размер сервера и не обещает прирост скорости.
Порядок обновления тоже остался за рамками сообщения. Неясно, нужны ли промежуточные версии, как меняется репозиторий и какие действия потребуются для возврата. Эти вопросы нужно закрыть документацией к поставке до переноса рабочего PPEM.
Наконец, слово «рекомендация» не раскрывает глубину совета. Это может быть точное действие с обоснованием или общее указание проверить autovacuum. Ответ даст только пилот на событиях, знакомых вашему администратору.
Решение после пилота
Готовьте PPEM 2.10 к рабочему внедрению, если выполнены четыре условия:
- Advisor запускается вручную и по расписанию;
- найденные события подтверждаются журналами и статистикой PostgreSQL;
- уровни Critical, High, Medium и Low помогают расставить порядок проверки;
- рекомендации ведут к проверяемой гипотезе, а не заканчиваются общим советом.
Оставьте текущую версию, если события Advisor нельзя связать с жалобами пользователей 1С. То же решение примите, если рекомендации не подтверждаются штатными средствами СУБД или пилот не прошёл проверку совместимости.
Внешнее хранилище ASH испытывайте после Advisor. Оно оправдано, когда история уже нагружает управляющий сервер или занимает заметную часть его диска. Без такого затруднения новая база усложнит контур и не решит текущую задачу.
Правило обновления простое: пресс-релиз отправляет версию в пилот, а не в рабочую среду. Рабочее внедрение начинается после того, как три обещания — обнаружение отклонений, полезный приоритет и проверяемая рекомендация — подтвердились на вашей телеметрии.