← На главную

При переходе с версии 1С:ЗУП 2.5 на 3.1 многие пользователи и администраторы сталкиваются с заметным падением производительности. Ситуация, когда документ Отпуск или Начисление зарплаты проводится первый раз за 30 секунд, а последующие разы быстрее, является классическим симптомом проблем с кэшированием, планами запросов и обслуживанием базы данных. Проанализируем ситуацию подробно и разберем по шагам, как привести систему в чувство.

Причина «раскачки» системы: кэширование и планы запросов

Рассмотрим, почему первая итерация проведения документа занимает 30 секунд, а четвертая — всего 4-5 секунд. Выясним причину такой «раскачки». В 1С:Предприятие 8.3 активно используется несколько уровней кэширования: кэш объектов на сервере приложений 1С и кэш данных (Buffer Pool) в SQL Server. При первом проведении система считывает данные с диска, что является самой медленной операцией. При повторных запусках данные уже находятся в оперативной памяти.

Однако более важным фактором является оптимизатор запросов SQL. При первом выполнении сложного запроса (а в ЗУП 3.1 запросы крайне громоздкие) SQL Server строит план выполнения. Если статистика базы данных устарела, первый запуск может уйти на построение неоптимального плана. Последующие запуски используют уже готовый (скомпилированный) план, что дает иллюзию ускорения. Наша задача — сделать так, чтобы даже первая итерация была максимально быстрой.

Анализ совместимости: SQL Server 2005 и современная 1С

Проанализируем программное окружение. Использование SQL Server 2005 совместно с ЗУП 3.1.10 на платформе 8.3.13 — это критический фактор замедления. Архитектура ЗУП 3.1 построена на использовании временных таблиц, вложенных запросов и механизмов, которые оптимизатор SQL 2005 обрабатывает неэффективно. Современные конфигурации 1С оптимизированы под логику работы SQL 2012 и выше.

Если вы используете виртуализацию на базе Windows 2008 R2, необходимо проверить выравнивание секторов диска (Disk Alignment). Для старых операционных систем это критично: неправильное выравнивание может снижать скорость дисковых операций на 30-50%. В современных ОС (начиная с Windows 2012) это происходит автоматически, но в связке 2005/2008 это нужно проверять вручную.

Настройка регламентного обслуживания SQL Server

Многие системные администраторы считают, что обслуживания раз в неделю достаточно. Для ЗУП 3.1 это заблуждение. Выясним, почему это так. В процессе расчета зарплаты 1С создает и удаляет огромное количество записей во временных таблицах. Статистика распределения данных устаревает катастрофически быстро.

Разберем правильный план обслуживания:

1. Обновление статистики (Update Statistics): В периоды активного расчета зарплаты (конец месяца, отчетные периоды) рекомендуется выполнять обновление статистики ежедневно или даже несколько раз в день. Это гарантирует, что SQL Server выберет правильный индекс для выполнения запроса.
2. Перестроение индексов (Rebuild Index): Вместо простой реорганизации (Reorganize), которая была упомянута в обсуждении, лучше использовать Rebuild. Важно помнить, что полное перестроение индекса автоматически обновляет статистику с полной выборкой (Fullscan), что гораздо качественнее обычного Update Statistics.
3. Параметр MAXDOP: Проверьте настройку Max Degree of Parallelism в свойствах SQL Server. Для баз 1С часто рекомендуемым значением является 1 (выполнение запроса в одном потоке), чтобы один тяжелый расчет не блокировал работу всех ядер процессора.

Влияние регламентных заданий 1С

В ЗУП 3.1, в отличие от 2.5, огромное количество механизмов вынесено в фоновые процессы. Если в консоли администрирования установлена блокировка регламентных заданий, система начинает вести себя непредсказуемо и медленно. Рассмотрим наиболее важные задания:

• Обновление индекса полнотекстового поиска: Если индекс поврежден, запись любого документа, использующего поиск, будет тормозить.
• Очередь расчета НДФЛ и перерасчетов: ЗУП 3 постоянно мониторит изменения. Если вы проводите «Отпуск», система параллельно проверяет регистр Перерасчеты. Если этот регистр раздут (содержит тысячи необработанных записей), проведение документа будет висеть, пока система не сопоставит все связи.

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

Оптимизация настроек расчета внутри программы

Разберем, как можно ускорить работу формы документа «Отпуск» программными средствами самой конфигурации. В ЗУП 3.1 реализован механизм автоматического пересчета «на лету».

Посмотрим на алгоритм действий:

1. Перейдите в раздел Настройка — Расчет зарплаты.
2. Найдите опцию «Выполнять автоматический пересчет документов при редактировании».
3. Если она включена — отключите её.

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

Аппаратные ресурсы и электропитание

Проанализируем ситуацию с виртуальным сервером. Одной из самых частых причин медленной «первой итерации» является режим энергосбережения процессора. Если на физическом хосте (гипервизоре) в BIOS или в настройках ОС стоит режим Balanced, процессор снижает частоту в моменты простоя. Когда пользователь нажимает «Провести», требуется время на «разогрев» и поднятие частот.

Обязательно выполните следующие настройки:

• Установите режим High Performance (Максимальная производительность) в настройках электропитания Windows на сервере 1С и сервере SQL.
• Если используется виртуализация VMware или Hyper-V, убедитесь, что ресурсы (особенно оперативная память) зарезервированы за виртуальной машиной (Memory Reservation), чтобы исключить использование файла подкачки (SWAP) на хосте.
• Проверьте антивирус. Исключите из сканирования файлы баз данных *.mdf, *.ldf, а также папки с серверным кэшем 1С (обычно это %AppData%\1C\1Cv8). При первой итерации антивирус может проверять создаваемые временные файлы, что и дает задержку в 30 секунд.

Таким образом, мы выяснили, что проблема медленного проведения в ЗУП 3.1 — это комплексный вопрос, требующий как правильного обслуживания SQL, так и настройки параметров самой программы и аппаратной части.