Нередко пользователи и администраторы систем 1С сталкиваются с ситуацией, когда регламентная операция «Закрытие месяца» выполняется часами или даже сутками, а в итоге завершается ошибкой или прерывается администратором. Особенно остро эта проблема стоит на крупных, высоконагруженных базах, работающих в клиент-серверном варианте, например, под управлением Linux и СУБД PostgreSQL. Давайте вместе разберемся, каковы могут быть причины такого поведения системы и как пошагово диагностировать и устранить проблему.
Проанализируем типичный случай: в 1С:Комплексная автоматизация 2 процедура закрытия месяца для конкретного квартала (например, третьего) запускается и работает более 10 часов без видимого результата, после чего сеанс принудительно завершается. При этом предыдущие периоды закрывались нормально. База серверная, работает на связке Linux + PostgreSQL, количество одновременных пользователей — около 30.
Такая ситуация требует комплексного подхода, так как причина может крыться как в данных, так и в технических настройках окружения. Рассмотрим основные направления для поиска неисправности.
Прежде чем переходить к сложному техническому анализу, всегда стоит выполнить несколько базовых проверок. Иногда решение лежит на поверхности.
Администрирование – Настройки пользователей и прав – Даты запрета изменения.Если эти простые действия не принесли результата, как и в разбираемом нами случае, переходим к более глубокому анализу.
Тот факт, что проблема проявляется только в третьем квартале, является ключевой подсказкой. Скорее всего, дело в специфике данных или настроек, которые начали действовать именно в этом периоде.
Регламентированный учет – Настройки и справочники – Учетные политики). Новые способы распределения затрат, изменение метода оценки себестоимости (например, с «По средней» на «ФИФО») могут кардинально изменить нагрузку на систему.Если анализ данных не дал результатов, проблема почти наверняка кроется в технической части: взаимодействии платформы 1С, сервера приложений и сервера СУБД. Для связки Linux и PostgreSQL это особенно актуально.
Стандартные настройки PostgreSQL часто не подходят для высоконагруженных баз 1С. Нехватка выделенной памяти для обработки сложных запросов — одна из главных причин «зависания» ресурсоемких операций.
Что нужно проверить в конфигурационном файле postgresql.conf:
shared_buffers — основной буфер кэша данных. Рекомендуемое значение — около 25% от общего объема оперативной памяти сервера СУБД.work_mem — память, выделяемая для операций сортировки, хэширования. Для закрытия месяца, где много сложных соединений и сортировок, низкое значение этого параметра может приводить к тому, что СУБД начинает сбрасывать временные данные на медленный диск, что резко снижает производительность. Попробуйте временно увеличить это значение для сеанса, выполняющего закрытие.effective_cache_size — подсказка для планировщика запросов о том, сколько памяти доступно для кэширования в операционной системе. Обычно устанавливается в 50-75% от общего объема ОЗУ.Также настоятельно рекомендуется использовать специализированные сборки PostgreSQL, адаптированные для работы с 1С, например, Postgres Pro. Они содержат патчи, которые значительно ускоряют выполнение специфических для платформы 1С запросов.
Закрытие месяца — это сложный процесс, состоящий из множества последовательных регламентных операций. Зависание может быть вызвано блокировкой таблиц другими процессами.
pg_locks). Это поможет понять, не ждет ли процесс закрытия освобождения ресурса, захваченного другим пользователем или фоновым заданием.Если процесс не заблокирован, а именно «крутится», значит, он выполняет некий очень ресурсоемкий запрос к базе данных.
DBPOSTGRS с условием по длительности), можно поймать тот самый SQL-запрос, который выполняется аномально долго.EXPLAIN ANALYZE). Неэффективный план (например, полный перебор таблицы вместо использования индекса) — частая причина проблем. Это может быть связано с устаревшей статистикой по таблицам.ANALYZE для всей базы данных. В некоторых случаях может помочь полная перестройка индексов (REINDEX) для самых больших и активно используемых таблиц регистров (например, РегистрНакопления.СебестоимостьТоваров, РегистрНакопления.ПартииТоваровОрганизаций).Наконец, нельзя исключать проблемы, связанные с конкретными версиями ПО. Как справедливо отмечают на форумах, проблема могла появиться после обновления.
Проверьте, не было ли обновлений (платформы 1С, конфигурации, операционной системы, СУБД) между успешным закрытием второго квартала и проблемным запуском для третьего. Известны случаи, когда в новых релизах платформы менялась логика генерации запросов, что в сочетании с определенной версией PostgreSQL приводило к деградации производительности. Проверьте на сайте 1С информацию о рекомендуемых версиях платформы и СУБД для вашей конфигурации.
Подводя итог, можно сказать, что бесконечное закрытие месяца — это симптом, за которым может стоять целый комплекс причин. Решение требует методичного подхода: от простых проверок к сложному техническому анализу серверной инфраструктуры и данных.