Переход со старой редакции 1С:Зарплата и управление персоналом 2.5 на управляемые формы ЗУП 3.1 для многих администраторов и бухгалтеров становится серьезным испытанием. С одной стороны, новая конфигурация предлагает развитый функционал и гибкие механизмы. С другой — пользователи начинают жаловаться на то, что элементарные операции (такие как расчет и вывод печатной формы «Расчетный листок») стали выполняться в 2–3 раза медленнее. При этом серверное железо может быть вполне производительным для других задач.
В этой статье мы подробно разберем, почему «тормозит» ЗУП 3.1, как правильно диагностировать проблемы производительности на уровне железа, виртуализации и СУБД, а также рассмотрим пошаговые методы ускорения системы.
---
Для начала проанализируем ситуацию с архитектурной точки зрения. Основное различие между старой и новой редакциями ЗУП заключается в переходе на управляемое приложение. В ЗУП 2.5 («обычные формы») значительная часть расчетов и визуализации выполнялась непосредственно на компьютере пользователя (клиентская часть). В ЗУП 3.1 применяется жесткое разделение на клиент и сервер. Почти все данные обрабатываются на сервере приложений 1С.
Кроме того, в ЗУП 3.1 кардинально изменилась схема хранения и получения расчетных данных:
Начисления, Удержания, регистры накопления по НДФЛ и взаиморасчетам). Отчет анализирует кадровые изменения, графики работы и фактически выполняет микро-расчет прямо во время формирования печатной формы.Все это приводит к тому, что нагрузка на процессор сервера приложений и СУБД возрастает многократно. Если процессор имеет низкую тактовую частоту, то даже при минимальном объеме базы данных и малом числе пользователей скорость работы будет неудовлетворительной.
---
Рассмотрим типовую аппаратную конфигурацию, часто встречающуюся на предприятиях: двухпроцессорный сервер на базе старых CPU (например, Intel Xeon E5630 с частотой 2.53 ГГц), достаточный объем ОЗУ DDR3 и RAID-массив из классических SAS-дисков со скоростью вращения 10k. При проведении теста производительности Гилева в виртуальной машине (ВМ) такая система показывает низкий результат (около 13 условных единиц), а на физическом сервере — порядка 25.
В чем же кроется главная аппаратная проблема? Платформа 1С критически чувствительна к производительности одного процессорного ядра (Single-Thread Performance). Многие внутренние операции СУБД и практически все расчетные алгоритмы в коде 1С выполняются последовательно (в один поток). Процессор с частотой 2.53 ГГц просто не способен быстро обработать сложный математический и логический код расчета зарплаты, сколько бы ядер у него ни было.
Посмотрим на практический пример из опыта модернизации оборудования:
Для небольшого количества пользователей (до 10–15 человек) высокая частота ядра важнее их количества. Многоядерность начинает приносить пользу только при значительном росте числа одновременно работающих сессий, когда серверу необходимо распределять множество рабочих процессов rphost.
---
При анализе логов СУБД MS SQL администраторы часто фиксируют высокий показатель ожидания типа ASYNC_NETWORK_IO. Многие ошибочно интерпретируют это как проблему сетевого оборудования или пропускной способности физических сетевых интерфейсов.
Разберем по шагам, что на самом деле означает это ожидание в контексте работы с 1С:
rphost) начинает забирать эти данные из буфера. Однако он делает это построчно или небольшими пакетами, параллельно выполняя сложные вычисления в цикле (например, расчет сложных формул начислений для каждого сотрудника).rphost занят обработкой текущей порции данных на уровне своего программного кода, он не может забрать следующую партию. SQL-сервер приостанавливает отправку и переходит в режим ожидания ASYNC_NETWORK_IO.Таким образом, высокое значение ASYNC_NETWORK_IO при локальном размещении СУБД и сервера 1С (или при их связи по быстрому каналу через протокол Shared Memory) однозначно указывает на то, что сервер приложений 1С «не успевает» переваривать данные, которые ему отдает MS SQL. Причина этого — медленная работа кода 1С на процессорах с низкой тактовой частотой.
---
Если сервер 1С и СУБД развернуты в виртуальной среде, неправильная настройка гипервизора может снизить производительность системы в два раза. Проанализируем ключевые параметры настройки ВМ.
Современные многопроцессорные серверы имеют архитектуру раздельного доступа к памяти. Каждому физическому процессору (сокету) принадлежит свой банк оперативной памяти (NUMA-узел). Обращение процессора к локальной памяти выполняется мгновенно. Если процессор обращается к памяти, подключенной к соседнему сокету, возникают серьезные задержки (inter-socket latency), которые губительны для СУБД и 1С.
Если вы выделяете для виртуальной машины с 1С количество виртуальных процессоров (vCPU), превышающее число физических ядер в одном сокете, гипервизор вынужден распределять потоки ВМ по разным сокетам. В результате виртуальная машина начинает постоянно работать с «чужой» памятью.
Рекомендация: Настраивайте параметры ВМ так, чтобы размер выделенных vCPU и оперативной памяти строго вписывался в границы одного физического NUMA-узла (одного физического процессора).
По умолчанию в BIOS серверов и в настройках гипервизоров включены функции динамического управления питанием (C-States, SpeedStep). При колебаниях нагрузки процессор сбрасывает частоту до минимума и повышает ее только при возникновении длительной пиковой нагрузки.
Специфика работы 1С — это генерация огромного количества коротких, но интенсивных транзакций. Процессор просто не успевает выйти из энергосберегающего режима во время выполнения короткого запроса, из-за чего транзакции выполняются на минимальной частоте ядра.
Рекомендация:
- В BIOS сервера установите профиль Static High Performance (Максимальная производительность).
- В панели управления гипервизора (например, VMware ESXi) измените схему электропитания на High Performance.
- Внутри гостевой операционной системы Windows Server выберите схему «Высокая производительность».
---
Начиная с версии ЗУП 3.1.9, разработчики фирмы «1С» существенно переработали архитектуру расчета зарплаты. Был внедрен новый оптимизированный программный объект МенеджерРасчетаЗарплаты, который выполняет пакетные расчеты в оперативной памяти с использованием временных таблиц в СУБД, минимизируя количество циклов обращения к серверу.
В ранних версиях (с 3.1.9 до 3.1.11) в программе существовала техническая константа Выполнять расчет зарплаты без оптимизации. Эта настройка создавалась для совместимости, чтобы пользователи могли обойти возможные ошибки нового механизма. Однако работа в режиме без оптимизации приводила к колоссальным задержкам.
В современных релизах (начиная с 3.1.18) фирма «1С» полностью исключила старые алгоритмы из кода. Если ваша база работает на устаревшем релизе, настоятельно рекомендуется выполнить обновление конфигурации до актуальной версии, где задействованы все последние механизмы оптимизации расчета НДФЛ, учета времени и интеграции с СЭДО.
---
Разберем пошагово комплекс административных мер, которые помогут существенно ускорить работу ЗУП 3.1 без покупки нового дорогостоящего сервера.
Интересной практической особенностью работы платформы 1С:Предприятие 8.3 является ускорение отрисовки и интерактивной работы интерфейсов при использовании веб-клиента или тонкого клиента через веб-сервер. Публикация базы данных на веб-сервере Apache позволяет оптимизировать передачу XML-пакетов между сервером и клиентом. Нередко время заполнения и проведения документов при таком подходе снижается в 1.5–2 раза.
Каждая включенная опция в ЗУП усложняет структуру SQL-запросов. Проанализируем настройки программы и отключим все функции, которые не используются на конкретном предприятии.
Перейдите в раздел Настройка -> Кадровый учет и Настройка -> Расчет зарплаты. Отключите следующие неиспользуемые флаги:
Чем проще логика расчетов, тем быстрее SQL-сервер формирует планы запросов.
В типовой конфигурации ЗУП 3.1 по умолчанию активировано большое количество фоновых процессов, которые могут непрерывно нагружать процессор и дисковую подсистему. Откроем список регламентных заданий в режиме «Администрирование» и настроим их расписание.
Рекомендуется отключить или перевести на ночное время следующие задания:
ИзвлечениеТекста (используется для полнотекстового поиска, создает высокую нагрузку на диски).ОбновлениеИндексаПолнотекстовогоПоиска.КлассификаторыРегламентированнаяОтчетность (автоматическое обновление через интернет).АктуализацияПроизводительности.Если на одном физическом сервере крутится много баз (например, рабочая ЗУП, Бухгалтерия и несколько тестовых копий), они по умолчанию могут обслуживаться одним процессом rphost. В таком случае тяжелый запрос в тестовой базе заблокирует процессорные потоки для пользователей рабочей базы.
Выясним причину взаимного влияния баз и настроим разделение:
Количество информационных баз на процесс.1.Это заставит платформу создавать для каждой базы данных свой изолированный процесс rphost, что повысит общую стабильность и скорость работы ключевых баз.
---
Для оптимизации работы СУБД с базой ЗУП важно правильно настроить параметры базы данных в SQL Server Management Studio. Разберем ключевой скрипт для настройки параметров авторасширения базы данных и лога транзакций.
По умолчанию Windows Server может выделять место под файлы СУБД мелкими фрагментами, что приводит к сильной фрагментации файлов на диске. Настроим фиксированное приращение файлов данных (mdf) и лога (ldf) с помощью следующего T-SQL скрипта:
ALTER DATABASE [Имя_Вашей_Базы_ЗУП]
MODIFY FILE ( NAME = N'Имя_Файла_Данных', FILEGROWTH = 512MB );
GO
ALTER DATABASE [Имя_Вашей_Базы_ЗУП]
MODIFY FILE ( NAME = N'Имя_Файла_Лога', FILEGROWTH = 256MB );
GO
Также обязательно убедитесь, что включена опция Read Committed Snapshot (RCSI). Это позволит СУБД использовать версионность строк при чтении данных, исключая взаимные блокировки пользователей при формировании отчетов и проведении документов начисления зарплаты.
---
Давайте подведем итог. Ускорение ЗУП 3.1 — это комплексная задача. Для получения максимального результата выполните следующие шаги:
Read Committed Snapshot.