← На главную

Анализ ситуации

Многие администраторы 1С сталкиваются с парадоксальной ситуацией: в файловом варианте закрытие месяца проходит за считанные минуты, тогда как на мощном сервере с MS SQL Server расчет себестоимости «висит» часами, потребляя при этом весь объем оперативной памяти. Рассмотрим, как проанализировать эту проблему и какие шаги предпринять.

Шаг 1. Первичная диагностика сервера баз данных

Прежде чем приступать к глубокому анализу кода 1С, необходимо исключить проблемы на уровне инфраструктуры. Разберем основные точки контроля:

1. Очистка процедурного кэша и статистика: SQL-сервер может хранить неэффективные планы выполнения запросов (Parameter Sniffing). Регулярное обновление статистики и очистка кэша процедур помогают «забыть» плохие планы.
2. Обслуживание индексов: Фрагментация индексов в таблицах регистров накопления критически замедляет операции чтения и записи при расчете себестоимости.
3. Настройки TEMPDB: Эта системная база данных активно используется для временных таблиц в ходе расчета. Убедитесь, что для нее выделено достаточное количество файлов (обычно по числу логических ядер процессора) и они размещены на самых быстрых SSD.
4. Настройка автоувеличения файлов: Проверьте параметры Autogrowth для базы данных. Значение в 1 Мб — это критическая ошибка, которая вызывает постоянные блокировки при расширении файлов базы во время транзакций. Установите фиксированный шаг (например, 256 Мб или 1024 Мб).

Шаг 2. Работа с планами обслуживания SQL

Для поддержания производительности настроим регламентные задания в MS SQL Server Management Studio. Рассмотрим типичный набор действий для поддержания БД в тонусе:

1. Обновление статистики: Настройте ежедневное обновление статистики по всем таблицам БД. Для таблиц с высокой интенсивностью операций (регистры накопления) обновление может потребоваться чаще.
2. Дефрагментация индексов: Если уровень фрагментации индекса превышает 30%, необходимо выполнить процедуру REBUILD, если меньше 30% — достаточно REORGANIZE.

Шаг 3. Использование инструментов 1С для выявления «узких мест»

Если обслуживание SQL не принесло результата, переходим к диагностике на стороне платформы 1С. Рассмотрим методы:

• Замер производительности: Запустите Замер производительности в Конфигураторе параллельно для файловой и серверной базы. Сравните, какие именно модули и процедуры потребляют больше всего времени в серверном варианте.
• Технологический журнал: Это «тяжелая артиллерия». Настройте фильтр на событие DBMSSQL. Вы сможете увидеть текст конкретных SQL-запросов, генерируемых платформой. Если запрос выполняется аномально долго, это даст понимание, какая именно часть алгоритма себестоимости дает сбой.

Шаг 4. Устранение ошибок конфигурации

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

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

1. Проверьте наличие вашей проблемы в списке исправленных ошибок (релизные заметки к последним обновлениям 1С).
2. Если проблема сохраняется на актуальном релизе, сформируйте обращение в техническую поддержку 1С с приложенным dt-файлом (если размер базы позволяет) или логами технологического журнала.
3. Используйте Тестирование и исправление (ТИИ) с включенными опциями проверки логической и ссылочной целостности, чтобы исключить влияние повреждений самой базы данных.

Рекомендация по минимизации рисков

Чтобы закрытие месяца не блокировало работу пользователей, следуйте правилам:

1. Запрет редактирования: Установите дату запрета редактирования данных для всех пользователей, чтобы исключить проведение документов задним числом в момент расчета себестоимости.
2. Предварительный расчет: Обязательно используйте функционал Предварительного расчета себестоимости. Он позволяет распределить нагрузку на сервер в течение дня и не дожидаться многочасового процесса в конце месяца.
3. Разграничение ресурсов: Если сервер перегружен, рассмотрите возможность выноса фоновых заданий расчета себестоимости на отдельный сервер 1С в кластере, чтобы они не конкурировали за ресурсы с терминальной сессией пользователей.

Помните: Если расчет себестоимости «съедает» 64 Гб памяти на небольшой базе в 1.7 Гб — это явный признак либо неоптимального плана выполнения запроса (из-за отсутствия статистики), либо алгоритмической ошибки в конфигурации. Взаимодействие с техподдержкой и мониторинг логов — ваш главный инструмент в таких ситуациях.