← На главную

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

1. Локализация и уточнение симптомов проблемы

Первым шагом необходимо конкретизировать, что именно понимается под «зависанием». Выясним у пользователей детали проявления проблемы:

1. Что именно работает медленно? Замедляется запуск программы, открытие конкретных форм, проведение документов или формирование какого-то одного тяжелого отчета?
2. Каков масштаб проблемы? Зависания происходят у всех пользователей или у одного сотрудника на конкретном рабочем месте?
3. Есть ли привязка ко времени? Торможение проявляется постоянно, в часы пиковой нагрузки или периодически при запуске фоновых процессов?

2. Анализ архитектуры и режима работы базы

Посмотрим на архитектуру информационного комплекса, так как методы диагностики принципиально отличаются для файлового и клиент-серверного вариантов:

Файловый режим: Проверим, где физически размещен файл 1Cv8.1CD (локально или в сетевой папке), а также его размер. При превышении объема 4–10 ГБ или одновременной работе более 5–10 пользователей файловая база начинает зависать из-за блокировки таблиц целиком при записи.

Серверный режим: Разберем параметры инфраструктуры:

1. Расположены ли сервер приложений 1С и СУБД (MS SQL, PostgreSQL) на одной машине или на разных серверах.
2. Как подключаются пользователи: через тонкий клиент, веб-клиент или в терминальном сеансе (RDP).
3. Настроено ли регулярное обслуживание СУБД (обновление статистики оптимизатора, дефрагментация индексов и очистка временных таблиц TempDB).

3. Замер производительности в Конфигураторе

Если неполадку удается воспроизвести локально или на тестовом контуре, разберем самый эффективный метод поиска узких мест в коде — встроенный инструмент отладки.

Для замера выполним следующие действия:

1. Запустим нужную конфигурацию в режиме Конфигуратор.
2. Перейдем в меню: Отладка — Замер производительности.
3. В открытом пользовательском сеансе выполним проблемное действие (например, проведем документ).
4. Остановим замер и проанализируем полученный отчет.

Проанализируем строки с максимальным суммарным временем выполнения и количеством вызовов. Чаще всего зависания вызваны циклами с запросами внутри, обращениями к виртуальным таблицам без указания параметров или сбоями при проверке прав RLS.

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

Когда проблема возникает хаотично на рабочей сервере и ее не удается воспроизвести в отладчике, задействуем Технологический журнал 1С (ТЖ). Настроим журнал на сбор следующих событий:

1. События CALL / SCALL: Регистрируют длительные серверные вызовы с указанием контекста исполнения.
2. События DBMSSQL / DBPOSTGRS: Фиксируют исполнение SQL-запросов к базе данных, превышающих заданный порог по времени.
3. События TLOCK и TDEADLOCK: Помогают обнаружить тайм-ауты на ожидание блокировок и взаимоблокировки при параллельной работе пользователей.
4. Событие EXCP: Регистрирует исключительные ситуации и аварийные завершения рабочих процессов rphost.

5. Проверка системных ресурсов и регламентных задач

Для завершения диагностики проверим аппаратные узкие места сервера и настройки программы:

1. Оперативная память и процессы: Проверим объем памяти, потребляемый процессами rphost. При наличии утечек памяти настроим лимиты и автоматический перезапуск процессов в консоли кластера 1С.
2. Дисковая подсистема: Проверим счетчики длины очереди диска (Disk Queue Length) и время отклика (latency).
3. Исключения антивируса: Убедимся, что каталоги с базами данных, временными файлами 1С и процессами rphost / rmngr добавлены в исключения антивирусного ПО.
4. Расписание регламентных заданий: Проанализируем, не совпадают ли тяжелые фоновые операции (обновление полнотекстового поиска, пересчет итогов, закрытие месяца) с рабочим временем пользователей.