Ситуация, когда после успешного восстановления базы данных PostgreSQL методами СУБД (например, через pg_dump и pg_restore) система 1С начинает работать медленно, встречается довольно часто. Проблема обычно проявляется в том, что тяжелые отчеты, которые ранее формировались за секунды, теперь выполняются часами. При этом восстановление того же дампа на другой сервер или в другую базу может показывать отличные результаты. Разберем подробно, почему так происходит, и проанализируем последовательность действий для возвращения былой скорости работы.
Когда мы восстанавливаем базу данных из дампа, PostgreSQL заново создает таблицы и индексы. Однако важная часть информации — статистика распределения данных (статистика гистограмм, количество уникальных значений в колонках) — часто не переносится в полном объеме или не создается автоматически сразу после загрузки. Планировщик запросов (Query Planner) в таких условиях «не знает» реального объема данных и выбирает неоптимальный план выполнения запроса, например, заменяя быстрый Index Scan на долгий Seq Scan (полное сканирование таблицы).
Для решения этой проблемы первым делом необходимо выполнить команду ANALYZE. Рассмотрим, как это сделать правильно:
pgAdmin или psql).
ANALYZE VERBOSE;
ANALYZE VERBOSE _referencetasks65; -- имя таблицы из структуры хранения 1С
Важный момент: для высоконагруженных баз 1С стандартного уровня сбора статистики может быть недостаточно. Попробуем увеличить параметр default_statistics_target в конфигурационном файле postgresql.conf со 100 до 500 или 1000, после чего повторно запустим ANALYZE. Это позволит планировщику строить более точные планы для сложных запросов 1С со множеством соединений.
Хотя при восстановлении индексы создаются заново, в процессе работы 1С (особенно если база «самописка» и в нее сразу после восстановления начали активно вносить изменения) индексы могут фрагментироваться или работать некорректно из-за специфики типов данных. Переиндексация помогает упорядочить структуру индексов и ускорить поиск.
Существует два подхода к переиндексации: средствами СУБД и средствами 1С. Рассмотрим их подробнее:
Переиндексация в PostgreSQL:
Выполняется командой REINDEX. Посмотрим на синтаксис для всей базы:
REINDEX DATABASE "Имя_Вашей_Базы";
Стоит учитывать, что эта операция блокирует таблицы, поэтому ее лучше выполнять в технологическое окно.
Переиндексация в 1С (Тестирование и исправление): Этот метод предпочтительнее, так как 1С пересоздает индексы в соответствии со своей внутренней логикой метаданных.
Если отчет строится по объектам типа Задача, обратите внимание на состояние индексов именно в этих таблицах.
Одной из специфических особенностей 1С является механизм итогов. Если отчет строится на основе регистров накопления или бухгалтерии, то 1С обращается к таблицам итогов. При некорректном восстановлении или сбое в датах (например, наличие записей будущим числом) система может решить, что итоги не рассчитаны, и начнет вычислять данные «на лету» с момента начала времен.
Разберем, как исправить ситуацию с итогами:
Если ANALYZE и REINDEX не помогли, нам нужно выяснить, почему для одних объектов отчет работает быстро, а для других — медленно. Для этого воспользуемся механизмом EXPLAIN.
Выясним причину замедления, выполнив следующие шаги:
pgAdmin и вставьте этот запрос в Query Tool.EXPLAIN (ANALYZE, BUFFERS).Пример анализа запроса:
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM _referencetasks65 WHERE _fld1025 = 'нужное_значение';
Проанализируем полученный результат. Если вы видите строку Seq Scan on _referencetasks65 там, где ожидался Index Scan, значит, планировщик ошибается. Если время в Actual time значительно превышает Planning time, возможно, проблема в нехватке оперативной памяти для сортировки (параметр work_mem в postgresql.conf).
Иногда при восстановлении на новый экземпляр сервера системные администраторы забывают применить оптимизированные настройки postgresql.conf, оставляя параметры «по умолчанию», которые рассчитаны на очень слабые машины. Для 1С критически важны следующие параметры:
shared_buffers — должен составлять около 25% от всей оперативной памяти.work_mem — определяет объем памяти для операций сортировки. Попробуйте установить 32MB или 64MB.effective_cache_size — ориентир для планировщика о доступном кэше ОС (обычно 50-75% RAM).maintenance_work_mem — важен для ускорения создания индексов и VACUUM.Если стандартные методы VACUUM, ANALYZE и ТИИ не помогают или не успевают выполниться в регламентное окно, можно рассмотреть механизм Распределенных Информационных Баз (РИБ). Это позволяет создать «чистый» узел-приемник и перенести туда данные на уровне бизнес-логики 1С, а не на уровне образов диска СУБД.
Рассмотрим этот процесс по шагам:
Заключение: В большинстве случаев после восстановления базы PostgreSQL медленная работа лечится последовательным выполнением ANALYZE, пересчетом итогов в 1С и проверкой параметров конфигурации СУБД. Всегда начинайте с обновления статистики, так как это самая быстрая и часто самая эффективная операция.