Монитор производительности (perfmon) 25.100.0 от 02.09.2025

  • Улучшен мастер миграции на PostgreSQL.
  • Исправлена ошибка при построении меню панели управления.
  • Исправлена ошибка БД при установке модуля на PostgreSQL.
02.09.2025 22:00
Поделиться:

Обновление в основном затрагивает поддержку PostgreSQL, улучшает работу с кастомными подключениями к БД и исправляет мелкие ошибки. Давайте разберем детали.

1. Ключевые изменения

Усилена валидация конфигурации PostgreSQL

Это главное изменение в коммите. Мастер миграции на PostgreSQL (perfmon.pgsql) теперь выполняет две важные проверки конфигурации сервера БД перед началом работы.

Что проверяется:

  1. standard_conforming_strings = on: Этот параметр гарантирует, что строки в SQL-запросах обрабатываются по стандарту, что исключает множество потенциальных проблем с экранированием и SQL-инъекциями.
  2. ac_ignore_maclabel = true (если опция доступна): Эта проверка специфична для окружений с MAC (Mandatory Access Control) и предотвращает возможные ошибки доступа.

Где это реализовано:

  • install/wizards/bitrix/perfmon.pgsql/wizard.php: Добавлена логика проверок.
  • install/wizards/bitrix/perfmon.pgsql/lang/.../wizard.php: Добавлены соответствующие сообщения об ошибках на нескольких языках.

⚠️ Важно: Если вы планируете миграцию на PostgreSQL с помощью встроенного мастера, теперь нужно будет убедиться, что ваш сервер соответствует этим требованиям. Это не "брейкинг", а скорее "фейл-сейф" — защита от развертывания на заведомо некорректной конфигурации.


Улучшена работа с множественными подключениями к БД

В административном меню модуля появилась поддержка кастомных подключений, объявленных в .settings.php, которые могут требовать предварительной загрузки своих модулей.

Было: Меню просто итерировало все $configParams и выводило ссылку для каждого соединения.

        // bitrix/modules/perfmon/admin/menu.php (старая версия)
foreach ($configParams as $connectionName => $connectionParams)
{
    $connections[] = [
        'text' => $connectionName,
        'url' => 'perfmon_tables.php?lang=' . LANGUAGE_ID . '&connection=' . urlencode($connectionName),
        // ...
    ];
}

    

Стало: Теперь перед формированием пункта меню происходит две проверки:

  1. Если для соединения указан модуль ($connectionParams['module']), он будет подключен через \Bitrix\Main\Loader::includeModule().
  2. Пункт меню будет создан, только если класс соединения ($connectionParams['className']) является наследником \Bitrix\Main\DB\Connection.
        // bitrix/modules/perfmon/admin/menu.php (новая версия)
if (isset($connectionParams['module']))
{
    \Bitrix\Main\Loader::includeModule($connectionParams['module']);
}

if (is_a($connectionParams['className'], '\Bitrix\Main\DB\Connection', true))
{
    $connections[] = [ /* ... */ ];
}

    

💡 Что это дает? Теперь в меню производительности будут корректно отображаться только валидные и активные подключения к базам данных, включая те, что реализованы в кастомных модулях (например, для работы с ClickHouse или другими экзотическими БД). Это делает модуль более гибким и отказоустойчивым в сложных конфигурациях.


2. Мелкие исправления и улучшения

Корректное удаление таблицы b_perf_cache_hitrate

В скрипт деинсталляции модуля для PostgreSQL добавлено удаление таблицы b_perf_cache_hitrate. Ранее она могла оставаться в базе данных после удаления модуля.

  • Файл: install/db/pgsql/uninstall.sql

Исправление в SQL-парсере

В классе \Bitrix\Perfmon\Sql\Table исправлен пограничный случай, когда парсер мог столкнуться с null-токеном, что приводило к ошибке. Теперь в такой ситуации токен принудительно заменяется на ;, что позволяет избежать падения.

  • Файл: lib/sql/table.php

Инсайт: Этот фикс — хороший пример "защитного" программирования. Он нацелен на обработку некорректных или неполных SQL-запросов, которые могут попасть в парсер, и делает его более устойчивым.


3. Интересные находки

В install/db/pgsql/install.sql изменился способ объявления индексов для таблицы b_perf_cache_hitrate. Ранее они были частью CREATE TABLE, теперь вынесены в отдельные команды CREATE UNIQUE INDEX и CREATE INDEX.

Было:

        CREATE TABLE b_perf_cache_hitrate (
    //...
    PRIMARY KEY(ID),
    UNIQUE INDEX UX_HASH(HASH),
    INDEX IX_B_PERF_CACHE_RATE(RATE)
);

    

Стало:

        CREATE TABLE b_perf_cache_hitrate (
    //...
    PRIMARY KEY(ID)
);
CREATE UNIQUE INDEX ux_hash ON b_perf_cache_hitrate (hash);
CREATE INDEX ix_b_perf_cache_rate ON b_perf_cache_hitrate (rate);

    

Это не меняет конечную структуру, но может быть связано с обеспечением лучшей совместимости между разными версиями PostgreSQL или является шагом к унификации скриптов установки.