Работа в крупной торгово-производственной компании на конфигурации Управление торговлей 11 (особенно старых версий, таких как 11.1) при достижении порога в 250 и более активных пользователей неизбежно приводит к проблемам производительности. Основными жалобами становятся "тормоза" интерфейса, длительные ожидания на блокировках, медленная работа механизмов RLS (ограничение доступа на уровне записей) и неконтролируемый рост журнала транзакций. Проанализируем ситуацию и разберем комплексный подход к решению этих задач — от настройки "железа" до изменения архитектуры кода.
При большом количестве пользователей стандартных настроек СУБД и серверов "из коробки" становится недостаточно. Рассмотрим основные рекомендации по дисковой подсистеме и настройкам SQL Server, которые позволяют существенно снизить время отклика системы.
Распределение файлов базы данных по дискам:
TempDB рекомендуется использовать высокоскоростные массивы RAID 0 (если критична скорость и есть надежная система бэкапов) или, что более предпочтительно для продакшена, RAID 10 на SSD/NVMe накопителях.Тонкая настройка SQL Server:
Разберем параметр MAXDOP (Maximum Degree of Parallelism). В высоконагруженных системах 1С настройка этого параметра в значение 1 часто является спасением. Если оставить значение по умолчанию (0), SQL Server может попытаться выполнить один тяжелый запрос (например, расчет себестоимости или отчет по RLS) на всех доступных ядрах процессора. Это приводит к возникновению ожиданий типа CXPACKET, когда остальные 249 пользователей стоят в очереди, пока одно ядро ждет другое.
Также проанализируем настройки TempDB. Рекомендуется создавать количество файлов данных TempDB, равное количеству логических ядер процессора (но обычно не более 8-12), и устанавливать им одинаковый начальный размер и шаг роста. Это минимизирует конкуренцию за страницы распределения памяти внутри SQL.
Одной из самых главных причин медленной работы в УТ 11.1 является механизм RLS. Выясним причину: в старых версиях системы 1С динамически подмешивает сложные подзапросы в каждый ваш запрос к базе данных. Если у пользователя ограничены права, например, по подразделениям или складам, то простая выборка из справочника превращается в монструозный SQL-запрос с множеством вложенных JOIN.
Как решить проблему RLS:
УТ 11.4 и выше реализован механизм, при котором права рассчитываются заранее в фоновом режиме и записываются в специальные вспомогательные таблицы. При обращении к данным происходит простое соединение с этой таблицей, что в разы быстрее старого метода. Если производительность RLS является критическим фактором, это весомый повод задуматься об обновлении.Когда в системе работают 250 пользователей, вероятность того, что двое захотят изменить один и тот же объект или ресурс (например, остатки на одном складе), стремится к 100%. Разберем, как уменьшить количество ожиданий на блокировках.
Разделение процессов:
Посмотрим на опыт коллег: часто эффективным решением является разделение торгового и производственного контуров. Если компания крупная, можно выделить производство в отдельную базу (например, 1С:УНФ или специализированное решение), оставив в УТ только торговлю. Это снижает нагрузку на таблицы остатков и регистры накопления.
Режим управления блокировками:
Убедитесь, что конфигурация работает в режиме управляемых блокировок. В УТ 11 это стандарт, но при интенсивных доработках программисты могли случайно использовать методы, приводящие к избыточным блокировкам таблиц целиком. Необходимо проанализировать код на предмет длительных транзакций внутри циклов.
// Пример неправильного кода, вызывающего блокировки:
Для Каждого Строка Из ТЧ Цикл
Объект = Строка.Ссылка.ПолучитьОбъект();
Объект.Записать(); // Транзакция открывается на каждой итерации
КонецЦикла;
// Правильный подход:
НачатьТранзакцию();
Попытка
Для Каждого Строка Из ТЧ Цикл
// Обработка данных
КонецЦикла;
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
КонецПопытки;
Рано или поздно встает вопрос обновления. В УТ 11.4 и 11.5 исправлено огромное количество багов учета и оптимизированы многие механизмы (например, Intercompany — передача товаров между организациями стала работать адекватнее). Однако, если у вас "море доработок", классическое обновление будет крайне болезненным.
Стратегия использования расширений:
Проанализируем современный подход к кастомизации. Вместо изменения типовой конфигурации, все новые доработки следует выносить в расширения. Это позволяет:
Если система критически доработана, рассмотрите вариант "заливки" актуальных остатков в чистую новую версию УТ 11.5 и постепенный перенос только самого необходимого функционала через расширения, отказываясь от тех доработок, которые уже реализованы в типовом функционале за последние годы.
Невозможно лечить "тормоза", не зная их точного источника. Для систем с 250 пользователями обязательным является внедрение мониторинга.
Что нужно отслеживать:
Full, убедитесь, что бэкап лога транзакций делается каждые 15–30 минут.SQL Server.Подводя итог, скажем: "волшебной кнопки" для ускорения УТ 11 не существует. Требуется комплексная работа — от приведения оборудования к стандартам высоконагруженных систем до ревизии кода RLS и постепенного перехода на современные релизы платформы и конфигурации.