Почему замедлился обмен между 1С:КА 2 и 1С:Розница 2 после переноса на новые сервера?

Переезд на новые серверные мощности — это всегда ответственный процесс, который часто преподносит неприятные сюрпризы в виде резкого снижения производительности. В данной ситуации мы столкнулись с классическим случаем: после перехода на арендованные серверы обмен данными между 1С:Комплексная автоматизация 2 (КА2) и 1С:Розница 2 (РТ2) замедлился настолько, что загрузка 7 тысяч документов стала занимать до 6 часов. Проанализируем ситуацию, выявим "узкие места" и определим последовательность действий для восстановления нормальной работы систем.

Разберем влияние дисковой подсистемы: HDD против SSD

Одной из главных причин деградации производительности стал перенос операционной системы и SQL Server на HDD, несмотря на то, что сами файлы базы данных остались на SSD. Рассмотрим, почему это критично для 1С:

1. Временная база TempDB: По умолчанию TempDB располагается в системном каталоге SQL Server. При выполнении обменов, особенно через механизмы EnterpriseData, 1С активно создает временные таблицы. Если TempDB находится на медленном HDD, любая операция записи во временные таблицы становится "бутылочным горлышком".
2. Журнал транзакций (.ldf): Если файл лога транзакций базы КА2 остался на HDD, это катастрофически замедляет любую запись. При загрузке документов каждый Commit транзакции требует физической записи в лог. Время отклика (latency) у HDD в десятки раз выше, чем у SSD.
3. Файл подкачки (Swap): Если серверу не хватает оперативной памяти и система начинает использовать файл подкачки на HDD, производительность всей ОС и приложений падает практически до нуля.

Решение: Обязательно перенесите TempDB и файлы журналов транзакций (.ldf) всех баз данных на SSD. Убедитесь, что системный раздел с файлом подкачки также не перегружен запросами к диску.

Проанализируем роль процессорных мощностей

В сообщениях упоминается, что новые процессоры "чуть хуже по частоте и кэшу". Для платформы 1С:Предприятие 8.3 тактовая частота ядра имеет решающее значение. Выясним причину: архитектура 1С во многом полагается на однопоточные вычисления при выполнении бизнес-логики (проведение документов, расчеты). Даже небольшое снижение частоты (например, с 3.5 ГГц до 2.8 ГГц) может дать ощутимое замедление на больших объемах данных.

Проверьте настройки электропитания на новом сервере. Часто арендованные сервера приходят с профилем Balanced, что заставляет процессор сбрасывать частоту. Установите профиль High Performance (Максимальная производительность) в настройках Windows и BIOS/UEFI.

Восстановим регламентные операции: Индексация и Статистика

Забытая индексация базы — это критическая ошибка. В 1С:КА 2, которая построена на метаданных ERP, таблицы содержат миллионы записей. Без актуальных индексов SQL Server вынужден выполнять Index Scan или Table Scan (полный перебор), что при загрузке 7000 документов убивает производительность.

Разберем по шагам, что нужно сделать в SQL Server Management Studio (SSMS):

• Полный ребилд индексов: Это устранит фрагментацию, возникшую после массового переноса данных.
• Обновление статистик: Это позволит оптимизатору SQL выбирать наиболее эффективные планы выполнения запросов.

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

USE [Имя_Вашей_Базы];
GO
EXEC sp_updatestats;
GO

Посмотрим на архитектурные особенности КА 2

Нужно понимать, что 1С:Комплексная автоматизация 2 — это тяжелое решение. В отличие от старых версий (УТ 10.3 или БП 2.0), здесь при записи документа происходит масса дополнительных действий. Рассмотрим подробнее:

1. RLS (Row Level Security): Если включено ограничение прав на уровне записей, система пересчитывает права при каждом обращении к данным. На слабом железе это дает огромную нагрузку.
2. Автоматическое проведение: Если в настройках обмена стоит "Проводить документы при загрузке", то 1С пытается выполнить сложные алгоритмы проведения. Проанализируем ситуацию: лучше загружать документы непроведенными, а затем проводить их в монопольном режиме или отдельной очередью.
3. Регистрация в узлах обмена: Проверьте, не копится ли огромная очередь сообщений на отправку обратно в РТ.

Настроим SQL Server под специфику 1С

При переезде часто забывают о тонкой настройке SQL Server. Рассмотрим параметры, которые могут влиять на блокировки и тормоза:

• Max Degree of Parallelism (MAXDOP): Для баз 1С рекомендуется устанавливать значение 1. Это предотвращает ситуацию, когда один тяжелый запрос захватывает все ядра процессора, вызывая простои других процессов.
• Memory Limit: Ограничьте аппетит SQL Server. Он должен оставлять минимум 4-8 ГБ оперативной памяти для операционной системы и процессов rphost (сервера приложений 1С).

Методика диагностики (куда копать админу)

Чтобы не гадать, используем инструменты замера производительности. Разберем план действий:

1. Счетчики производительности Windows (PerfMon): Настройте мониторинг показателей PhysicalDisk \ Avg. Disk Queue Length (длина очереди к диску) и Processor \ % Processor Time. Если очередь к диску выше 2 — диски не справляются.
2. Технологический журнал 1С (ТЖ): Настройте сбор событий DBMSSQL и EXCP. Это покажет, какие именно SQL-запросы выполняются дольше всего.
3. Замер производительности в конфигураторе: Запустите загрузку одного "тяжелого" документа под отладкой и посмотрите, в каких процедурах (ПриЗаписи, ОбработкаПроведения) система "висит" дольше всего.

Как быть с очередью за временем?

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

• Расчет итогов: Проверьте актуальность итогов в КА. Если итоги не рассчитаны на текущий месяц, система будет пересчитывать их "на лету" при каждом проведении документа.
• Ночной расчет себестоимости: Это тяжелая процедура. Если за полгода себестоимость не считалась, первый запуск может длиться сутки. Рекомендуем сначала закрыть прошлые периоды помесячно в копии базы, чтобы понять реальное время выполнения, и только потом запускать в рабочей.
• Оптимизация загрузки: Используйте фоновую загрузку данных в несколько потоков, если позволяют ресурсы процессора, или разделите загрузку по типам документов.

Итог: Проблема носит комплексный характер. Первоочередная задача — вернуть TempDB и логи на SSD, выполнить полный ребилд индексов и настроить MAXDOP. После этого необходимо провести замер производительности и убедиться, что дисковая очередь пришла в норму.