В практике администрирования высоконагруженных систем 1С часто возникают ситуации, когда после обновления платформы или изменения архитектуры (например, настройки зеркалирования) производительность резко падает. Отчеты, формировавшиеся за минуты, начинают выполняться десятки минут, а регламентные задания "подвисают". Разберем сложный кейс диагностики производительности, где причина крылась не в коде конфигурации и не в "железе", а в настройках технологического журнала и особенностях работы дисковой подсистемы.
Рассмотрим типичную ситуацию. Имеется база данных объемом более 150 ГБ. После перевода базы в модель восстановления "Полная" (Full Recovery Model) и включения зеркалирования (Mirroring) начались серьезные проблемы:
При этом стандартные меры — перезагрузка сервера, очистка сеансового кэша, отключение зеркалирования — не помогают. Даже восстановление базы на аналогичный сервер (эталонный) показывает нормальную скорость, что ставит в тупик: "железо" одинаковое, версии ПО одинаковые, а результат разный.
В ходе расследования выяснилось, что наиболее критическое влияние на производительность оказал параметр технологического журнала 1С.
Одной из попыток диагностики было включение параметра SCRIPTCIRCREFS в файле настройки технологического журнала logcfg.xml. Этот параметр предназначен для отладки и поиска утечек памяти, вызванных циклическими ссылками во встроенном языке.
Почему это "убивает" производительность?
Механизм работы с памятью в 1С основан на подсчете ссылок. Обычно память освобождается, когда счетчик ссылок на объект становится равен нулю. Однако, если Объект А ссылается на Объект Б, а Б — обратно на А, счетчики не обнуляются.
Когда мы включаем SCRIPTCIRCREFS, платформа активирует сложный алгоритм анализа графа объектов в памяти. Вместо простой арифметики (плюс/минус ссылка), системе приходится постоянно сканировать связи, чтобы найти замкнутые циклы.
Это создает колоссальную нагрузку на рабочий процесс сервера приложений (rphost), особенно при выполнении отчетов и обработок, которые создают тысячи временных объектов.
Решение:
Проверьте файл logcfg.xml на сервере 1С. Если вы не занимаетесь целенаправленным поиском утечек памяти на тестовом контуре, убедитесь, что параметр SCRIPTCIRCREFS отключен или удален. Как показала практика, удаление этого параметра мгновенно возвращает скорость формирования отчетов к нормальным показателям.
Второй важный момент, обнаруженный при диагностике — ошибки в логах SQL Server вида:
There have been 60160 misaligned log IOs which required falling back to synchronous IO.
Это сообщение указывает на проблему несоответствия размера сектора физического диска и ожиданий SQL Server. Суть проблемы: Журнал транзакций SQL Server (LDF) исторически оптимизирован для записи блоками по 512 байт. Современные SSD (особенно NVMe) часто имеют физический сектор 4096 байт (4Kn) без эмуляции 512 байт (512e). Когда SQL Server пытается записать 512 байт, а диск умеет писать только по 4096 байт, происходит операция RMW (Read-Modify-Write):
Это приводит к переходу в режим синхронного ввода-вывода (Synchronous IO), что драматически снижает скорость транзакций, особенно при включенном зеркалировании или полной модели восстановления, где активность записи в журнал очень высока.
Как проверить:
Выполните в командной строке Windows команду для диска, где лежат файлы базы и логов (например, диск E:):
fsutil fsinfo sectorinfo E:
Если вы видите:
PhysicalBytesPerSectorForAtomicity : 4096
PhysicalBytesPerSectorForPerformance : 4096
Это означает, что у вас диск 4Kn.
Что делать:
Для корректной работы SQL Server на таких дисках рекомендуется форматировать тома с размером кластера файловой системы, отличным от стандартного (часто рекомендуют 64 КБ), и убедиться, что ваша версия SQL Server полностью поддерживает нативные сектора 4K. В некоторых случаях требуется настройка флагов трассировки или перенос журналов транзакций на диск с эмуляцией 512e.
Если проблема не решается очевидными настройками, необходимо разделить зоны ответственности: виноват SQL Server или сервер приложений 1С? Для этого можно использовать методику "чистого теста канала памяти и сети", исключив SQL Server из уравнения. Способ 1: Генерация большого отчета без SQL Попросите программиста создать внешнюю обработку или отчет, который генерирует данные программно, не обращаясь к базе данных. Пример кода для генерации данных в модуле менеджера или внешней обработке:
&НаСервере
Функция СформироватьТяжелыйМакет()
// Создаем искусственную таблицу данных
ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("Дата", Новый ОписаниеТипов("Дата"));
ТЗ.Колонки.Добавить("Число", Новый ОписаниеТипов("Число"));
ТЗ.Колонки.Добавить("Строка", Новый ОписаниеТипов("Строка"));
// Наполняем большим количеством строк
Для сч = 1 По 100000 Цикл
НС = ТЗ.Добавить();
НС.Дата = ТекущаяДата();
НС.Число = сч;
НС.Строка = "Тестовая строка для проверки объема " + сч;
КонецЦикла;
// Возвращаем данные или помещаем их в макет для передачи на клиент
Возврат ТЗ;
КонецФункции
Что это дает? Если выполнение такого кода и передача результата на клиент занимает одинаковое время на "сбойном" и "эталонном" серверах, значит:
Следовательно, проблему нужно искать на уровне СУБД (блокировки, статистика, планы запросов) или взаимодействия rphost <-> dbmssocn. Способ 2: Сравнение "чистого" запроса Выделите текст SQL-запроса, который генерирует платформа при выполнении отчета (можно получить через Технологический журнал или SQL Profiler). Выполните этот запрос напрямую в SQL Server Management Studio на проблемном и эталонном серверах.
SCRIPTCIRCREFS).Не стоит забывать про сетевой уровень. Существуют случаи, когда проблема кроется в настройках MTU или обработке пакетов маршрутизаторами (DPI, Firewall). Бывает, что мелкие пакеты проходят быстро, а крупные (при передаче больших отчетов) начинают дропаться или проверяться слишком долго. Если "синтетический" тест с передачей большого файла или макета (см. Способ 1) показывает существенную разницу между серверами, при этом локальная нагрузка на CPU минимальна — привлекайте сетевых администраторов для проверки канала связи между клиентом и сервером приложений, а также между сервером приложений и SQL Server.
При диагностике "тормозов" в 1С:
logcfg.xml и отключите все отладочные параметры, особенно SCRIPTCIRCREFS.