Монитор производительности (perfmon) 25.100.0 от 02.09.2025
- Улучшен мастер миграции на PostgreSQL.
- Исправлена ошибка при построении меню панели управления.
- Исправлена ошибка БД при установке модуля на PostgreSQL.
Обновление в основном затрагивает поддержку PostgreSQL, улучшает работу с кастомными подключениями к БД и исправляет мелкие ошибки. Давайте разберем детали.
1. Ключевые изменения
Усилена валидация конфигурации PostgreSQL
Это главное изменение в коммите. Мастер миграции на PostgreSQL (perfmon.pgsql
) теперь выполняет две важные проверки конфигурации сервера БД перед началом работы.
Что проверяется:
standard_conforming_strings = on
: Этот параметр гарантирует, что строки в SQL-запросах обрабатываются по стандарту, что исключает множество потенциальных проблем с экранированием и SQL-инъекциями.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),
// ...
];
}
Стало: Теперь перед формированием пункта меню происходит две проверки:
- Если для соединения указан модуль (
$connectionParams['module']
), он будет подключен через\Bitrix\Main\Loader::includeModule()
. - Пункт меню будет создан, только если класс соединения (
$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 или является шагом к унификации скриптов установки.