Как вычислить пользователя, который замедляет работу файловой базы 1С:Бухгалтерия 3.0?

Работа в файловом варианте 1С нередко сопровождается ситуациями, когда действия одного пользователя «подвешивают» всю систему. Когда кто-то запускает массовое проведение документов или выполняет тяжелую обработку, остальные участники процесса сталкиваются с ожиданием блокировок. Давайте разберем, как вычислить «виновника» и какие инструменты помогут нам проанализировать ситуацию.

Анализ через Журнал регистрации

Первым делом мы обращаемся к стандартному инструменту платформы — Журналу регистрации. В файловом варианте он хранится в папке с базой данных в подкаталоге 1Cv8Log. Файлы с расширением lgd содержат всю историю действий пользователей.

Для поиска проблемных операций выполним следующие шаги:

1. Откроем Журнал регистрации через Конфигуратор или режим 1С:Предприятие.
2. Настроим отбор по событию «Проведение документа» или «Начало сеанса».
3. Проанализируем события, которые длились аномально долго.
4. Обратим внимание на пользователей, чьи действия совпадают по времени с жалобами остальных коллег на «зависания».

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

Использование Технологического журнала

Если журнал регистрации не дает полной картины, переходим к более «тяжелой артиллерии» — Технологическому журналу. Это инструмент, который позволяет отслеживать события на уровне взаимодействия платформы с файловой системой и СУБД.

Чтобы настроить его работу, нам необходимо создать файл конфигурации logcfg.xml в папке с базой или в каталоге установки платформы. В файловой базе 1С технологический журнал пишется локально на стороне того клиента, который инициирует нагрузку. Чтобы централизованно собирать данные, рекомендуется настроить запись логов в общую сетевую папку.

Пример настройки logcfg.xml для отслеживания длительных событий:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\Logs" history="24">
        <event>
            <eq property="Name" value="DBMSSQL"/>
        </event>
        <property name="Duration"/>
        <property name="SQL"/>
    </log>
</config>
</config>

После сбора данных мы сможем проанализировать файлы логов и найти те самые «тяжелые» запросы, которые блокируют работу файловой системы (файловые блокировки) на длительное время.

Анализ регламентных заданий

Не всегда виноват «живой» пользователь. Часто причину стоит искать в фоновых процессах. Проверим файл jobs.dat, который находится по пути BP_3.0\1Cv8JobScheduler\jobs.dat. Этот файл отвечает за планирование заданий. Если в рабочее время запущены тяжелые обмены или пересчеты итогов, они могут приводить к точно таким же последствиям.

Архитектурные решения для файловой базы

Если мы часто сталкиваемся с проблемой блокировок, значит, файловая база перестала справляться с текущей нагрузкой. Рассмотрим следующие варианты оптимизации:

• Переход на клиент-серверный вариант (SQL): Это радикальный, но самый эффективный способ управления блокировками. СУБД (например, MS SQL Server или PostgreSQL) управляет блокировками на уровне записей, что в десятки раз эффективнее файловых блокировок ОС.
• Использование веб-сервера (IIS или Apache): Перевод пользователей на работу через веб-клиент позволяет более гибко распределять запросы и уйти от проблем прямого доступа к файлу 1CD.
• Мини-сервер 1С: Если покупка полнофункционального сервера 1С кажется избыточной, решение «мини-сервер» на 5 подключений позволит нам использовать все преимущества серверного варианта работы, сохранив бюджет.

Разбираясь в причинах тормозов, мы не только находим конкретного пользователя, но и проводим аудит производительности системы. Постоянный мониторинг через Журнал регистрации и использование Технологического журнала позволят нам оперативно реагировать на возникающие задержки и поддерживать работоспособность базы на должном уровне.