При переходе на новые релизы 1С:ERP Управление предприятием 2.5 многие технические специалисты сталкиваются с деградацией производительности при проведении документов. Проблема может проявляться даже на мощном серверном оборудовании, когда время записи и проведения простых документов увеличивается в несколько раз. В этой статье мы подробно разберем основные причины замедления, проанализируем неоптимальный код в типовых механизмах и рассмотрим пути оптимизации серверной части.
Одной из скрытых причин замедления проведения любых документов в ERP (не только кадровых) является работа Библиотеки зарплаты и кадров (БЗК), которая интегрирована в состав ERP. Исследуем механизм проверки дат запрета изменения объектов. Выясним причину, по которой система может устанавливать исключительные блокировки там, где это не требуется для оперативной работы.
Проанализируем код в модуле менеджера регистра сведений РазделыДатЗапретаИзмененияОбъектовБЗК. Рассмотрим функцию ИсточникиПроверкиДатЗапретаИзменения(). В типовом решении часто встречается следующий подход:
Функция ИсточникиПроверкиДатЗапретаИзменения()
ИсточникиПроверки = Новый Структура();
НачатьТранзакцию();
Попытка
БлокировкаДанных = Новый БлокировкаДанных;
ЭлементБлокировкиДанных = БлокировкаДанных.Добавить("РегистрСведений.РазделыДатЗапретаИзмененияОбъектовБЗК");
ЭлементБлокировкиДанных.Режим = РежимБлокировкиДанных.Исключительный;
БлокировкаДанных.Заблокировать();
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РазделыДатЗапретаИзмененияОбъектов.РазделСсылка КАК РазделСсылка,
| РазделыДатЗапретаИзмененияОбъектов.ОбъектМетаданных КАК ОбъектМетаданных,
| РазделыДатЗапретаИзмененияОбъектов.ОбъектМетаданных.ПолноеИмя КАК Таблица
|ИЗ
| РегистрСведений.РазделыДатЗапретаИзмененияОбъектовБЗК КАК РазделыДатЗапретаИзмененияОбъектов";
ТаблицаНабора = Запрос.Выполнить().Выгрузить();
// Проверка необходимости обновления кэша
Если Константы.ВерсияДанныхДатЗапретаИзмененияБЗК.Получить() <> Метаданные.Версия Тогда
// Выполнение тяжелой магии по перезаполнению...
КонецЕсли;
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ВызватьИсключение;
КонецПопытки;
КонецФункции
В чем заключается проблема? Проанализируем ситуацию: при каждом проведении любого документа система входит в эту транзакцию и устанавливает исключительную блокировку на весь регистр РазделыДатЗапретаИзмененияОбъектовБЗК. Это происходит еще ДО того, как система проверит, нужно ли ей вообще что-то обновлять (сравнение версии метаданных с константой). Если в системе одновременно работают десятки пользователей, такая логика создает огромную очередь на ожидание блокировок, что визуально воспринимается как "зависание" проведения на 3-5 секунд даже в пустой базе.
Начиная с версии 2.5.8, компания 1С внедрила обновленные механизмы проведения документов. Рассмотрим, как это влияет на производительность:
rphost.Если программный код типовой и вы убедились, что лишних блокировок в расширениях нет, следует обратить внимание на настройки MSSQL Server и сервера приложений 1С. Разберем ключевые параметры для стабильной работы ERP 2.5:
Параметр MAXDOP (Max Degree of Parallelism): На мощных многоядерных процессорах (например, Intel Xeon Gold) SQL Server может пытаться распараллелить выполнение одного запроса на множество ядер. Для 1С это часто приводит к взаимным блокировкам (deadlocks) при проведении. Рекомендуется установить значение MAXDOP = 1. В некоторых случаях допустимо значение 2 или 4, но это требует тщательного тестирования.
Shared Memory: Если сервер 1С и SQL Server установлены на одной физической машине, обязательно проверьте использование протокола Shared Memory вместо TCP/IP. Это позволяет существенно ускорить передачу больших таблиц значений между процессами 1С и СУБД.
Настройка оперативной памяти: Для ERP 2.5 объем памяти имеет критическое значение. Как мы выяснили ранее, новые механизмы проведения активно используют кэширование таблиц в памяти. Настройка ограничения памяти для SQL Server должна оставлять достаточно места (не менее 10-20% общего объема) для работы процессов rphost, иначе система начнет использовать файл подкачки, что обрушит производительность.
Для того чтобы понять, является ли время проведения "типовым", выполним следующие шаги:
Записать() наборов записей и вызовы функций проверки дат запрета.Если вы видите, что основное время уходит на выполнение Запрос.Выполнить(), значит, проблема в индексах или статистике SQL. Если же время тратится на системные вызовы ожидания блокировок (как в случае с БЗК), то необходимо оптимизировать код проверки через расширение, вынося установку блокировки под условие проверки версии данных.
Рассмотрим пример оптимизированной проверки:
// В расширении для модуля менеджера регистра РазделыДатЗапретаИзмененияОбъектовБЗК
&Вместо("ИсточникиПроверкиДатЗапретаИзменения")
Функция Опт_ИсточникиПроверкиДатЗапретаИзменения()
// Сначала проверяем условие БЕЗ блокировки
Если Константы.ВерсияДанныхДатЗапретаИзмененияБЗК.Получить() = Метаданные.Версия Тогда
// Возвращаем данные из кэша или обычным запросом без исключительной блокировки
// ...
Иначе
// Только если версии не совпали, вызываем типовую логику с блокировкой
Возврат ПродолжитьВызов();
КонецЕсли;
КонецФункции
Такой подход позволяет избежать монопольного захвата ресурсов при каждом действии пользователя, значительно повышая общую отзывчивость 1С:ERP 2.5 в многопользовательском режиме.