Уважаемые коллеги, давайте вместе разберем одну из распространенных и крайне неприятных проблем, с которой могут столкнуться администраторы и разработчики 1С: резкое снижение производительности отчетов и регламентных заданий без видимых на то причин. Мы рассмотрим ситуацию, когда даже после отката всех изменений и перезагрузок, система продолжает "тормозить", хотя на другом, аналогичном сервере, все работает штатно. Выясним потенциальные причины такого поведения и предложим комплексные решения.
Начнем с анализа типичной ситуации: у вас есть большая база данных 1С (например, 150Гб+), работающая на MS SQL Server. Внезапно отчеты, которые раньше формировались за считанные минуты, начинают выполняться 20-25 минут, а регламентные задания, такие как "Групповое перепроведение ИПЧ", занимают неприемлемо много времени. При этом нагрузка на CPU и RAM находится в норме, а утилизация дисков, по данным Windows-счетчиков, минимальна.
Мы проанализируем различные аспекты проблемы, от неочевидных настроек до глубокой диагностики дисковой подсистемы и SQL Server. Наша цель – не просто найти временное решение, но и понять первопричину возникновения тормозов.
Часто в поисках причин замедления работы системы мы активно используем инструменты диагностики, такие как Технологический журнал (ТЖ) 1С. Однако, как показывает практика, сам процесс сбора данных ТЖ может стать причиной значительного снижения производительности, если включены слишком детализированные или ресурсоемкие параметры.
Рассмотрим подробнее один из таких параметров, который оказался причиной проблем в нашем случае – это SCRIPTCIRCREFS. Данный параметр предназначен для диагностики использования циклических ссылок при работе встроенного языка 1С. Он очень полезен для разработчиков, но его включение на продуктивной базе данных может иметь катастрофические последствия для производительности.
Выясним причину: Когда параметр SCRIPTCIRCREFS активен, платформа 1С вынуждена постоянно отслеживать и анализировать все ссылки между объектами в оперативной памяти. Это создает огромные накладные расходы на выполнение кода, замедляя даже типовые операции и регламентные задания, особенно в больших и сложных конфигурациях. Информационно-технологическое сопровождение (ИТС) 1С прямо указывает, что "Использование данной возможности может негативно сказаться на производительности прикладного решения. Рекомендуется использовать данную возможность только для целей тестирования". В нашем случае "может" превратилось в "точно негативно скажется".
Что мы делаем: Первым делом, если вы недавно включали какие-либо параметры Технологического журнала, особенно SCRIPTCIRCREFS, немедленно отключите его. Для этого нам нужно отредактировать файл конфигурации Технологического журнала (обычно logcfg.xml). Найдите секцию, отвечающую за сбор событий SCRIPTCIRCREFS, и либо удалите ее, либо закомментируйте. После изменения файла конфигурации ТЖ необходимо перезапустить службу сервера 1С:Предприятия.
Посмотрим на пример конфигурации ТЖ, где включен SCRIPTCIRCREFS:
<log location="F:\1C_logs\ScriptCircRefs" history="48">
<event>
<eq property="Name" value="SCRIPTCIRCREFS"/>
</event>
<property name="All"/>
</log>
Для отключения достаточно удалить или закомментировать эту секцию. После перезапуска процесса платформы, эффект может быть мгновенным.
Проанализируем ситуацию с другими параметрами ТЖ. Помимо SCRIPTCIRCREFS, существуют и другие параметры, которые при некорректном использовании могут замедлять систему:
CALL с большой детализацией: Сбор информации о каждом вызове метода встроенного языка может быть крайне ресурсоемким. Если вы не фильтруете вызовы по возвращаемым исключениям (RetExcp) или другим условиям, объем записываемых данных и накладные расходы на их сбор будут огромными. Используйте этот параметр только с фильтрами, например, для отслеживания ошибок.DBMSSQL без фильтрации: Запись всех SQL-запросов, выполняемых платформой, также генерирует гигантский объем данных и создает дополнительную нагрузку на дисковую подсистему и процессор. Мы рекомендуем фильтровать запросы по длительности (Duration), количеству строк (Rows) или по тексту (Sql), чтобы собирать только значимые, медленные запросы.Давайте разберем еще одну критическую проблему, которая может значительно влиять на производительность SQL Server и, как следствие, на работу 1С: неправильное выравнивание операций ввода-вывода (misaligned log IOs).
Выясним причину: Если в логах MSSQL вы видите сообщения вида "There have been 60160 misaligned log IOs which required falling back to synchronous IO", это является ключевым индикатором серьезной проблемы. Это означает, что SQL Server обнаруживает несоответствие между размером сектора, который он ожидает (часто 512 байт или 4096 байт при правильной конфигурации), и физическим размером сектора на диске (на современных Advanced Format дисках это обычно 4096 байт или 4КБ). В результате, вместо выполнения одной операции записи, диску приходится выполнять цикл "чтение-изменение-запись" (Read-Modify-Write), что резко снижает производительность ввода-вывода.
Посмотрим на пример: В нашем случае, сравнение параметров дисков с помощью команды fsutil fsinfo sectorinfo E: на проблемном и нормальном серверах показало существенную разницу:
PhysicalBytesPerSectorForAtomicity : 4096, PhysicalBytesPerSectorForPerformance : 4096. Это указывает, что диск физически оперирует 4КБ секторами.PhysicalBytesPerSectorForAtomicity : 512, PhysicalBytesPerSectorForPerformance : 512. Этот диск эмулирует 512-байтные сектора.Когда SQL Server пытается записать данные или лог-файлы блоками, которые не совпадают с физическим размером сектора диска (например, пишет 512 байт на 4КБ сектор), операционной системе и диску приходится выполнять дополнительную работу: читать весь 4КБ сектор, изменять часть 512 байт, а затем записывать весь 4КБ сектор обратно. Сообщение "falling back to synchronous IO" означает, что вместо быстрых асинхронных операций, SQL Server вынужден ждать завершения каждой записи, что еще больше замедляет работу.
Проанализируем ситуацию: Почему эта проблема могла проявиться именно при переходе на полную модель восстановления и включении зеркалирования? Полная модель восстановления и зеркалирование значительно увеличивают объем записей в журнал транзакций (ЖТР). Если дисковая подсистема работает неэффективно из-за misaligned IOs, эта дополнительная нагрузка быстро выявляет и усугубляет проблему.
Разберем по шагам диагностику и решение этой фундаментальной проблемы:
Используйте утилиту DISKPART в командной строке. Запустите DISKPART, затем выполните команды:
list disk
select disk X (где X - номер вашего диска)
list partition
select partition Y (где Y - номер раздела)
detail partition
Обратите внимание на значение Offset (смещение). Для 4K секторов смещение должно быть кратно 4096 байтам (например, 1024 KB = 1048576 байт, что кратно 4096). Если смещение не кратно 4096, раздел выровнен неправильно.
Если разделы выровнены неправильно, единственное надежное решение – это пересоздание разделов и переформатирование диска с правильным выравниванием. Это разрушительная операция, поэтому обязательно сделайте полный бэкап всех данных. При создании разделов убедитесь, что смещение кратно 4096 байтам (например, 1MB или 8MB). Современные ОС обычно делают это автоматически, но всегда стоит перепроверить.
Проверьте наличие последних обновлений для драйверов контроллера диска (особенно для RAID-контроллеров, если они используются) и прошивки самих NVME SSD. Производители регулярно выпускают исправления, которые могут решать проблемы с 4K секторами.
Убедитесь, что все файлы SQL Server (файлы данных .mdf, журналы транзакций .ldf, а также база данных tempdb) расположены на правильно выровненных разделах.
Важно отслеживать счетчики производительности диска более детально, чем просто утилизацию. Используйте Perfmon или Resource Monitor для анализа:
PhysicalDisk\Avg. Disk sec/ReadPhysicalDisk\Avg. Disk sec/WritePhysicalDisk\Current Disk Queue LengthPhysicalDisk\Disk Bytes/secPhysicalDisk\Disk Transfers/secСравните эти показатели на "нормальном" и "проблемном" серверах во время выполнения одного и того же отчета. Высокие значения Avg. Disk sec/Read и Avg. Disk sec/Write при низкой утилизации могут указывать на проблемы с выравниванием.
Даже если проблема с дисками устранена, или если она изначально не была основной, всегда есть возможность для оптимизации работы SQL Server и запросов 1С. Рассмотрим, куда еще можно "копнуть".
Разберем по шагам основные направления оптимизации:
Если отчеты или регламентные задания все еще выполняются медленно, нам необходимо проанализировать планы выполнения SQL-запросов. Запустите проблемный отчет и с помощью SQL Server Management Studio (SSMS) соберите "estimated xml plan" или "actual execution plan" для самых медленных запросов. Обращайте внимание на:
Table Scan (сканирование всей таблицы), Key Lookup, Bookmark Lookup (дополнительные обращения к таблице по индексу).lazy table spool: Может указывать на неоптимальные соединения или обработку временных данных.Используйте Extended Events или SQL Server Profiler для сбора статистики по длительности и ресурсам, потребляемым запросами 1С.
Вы уже упомянули, что на сервере проводятся регламенты по реорганизации/перестроению индексов и обновлению статистики. Это правильный подход. Однако убедитесь, что они действительно эффективно работают и охватывают все необходимые индексы и таблицы, особенно те, которые участвуют в медленных запросах. Проверьте актуальность статистики с помощью команды DBCC SHOW_STATISTICS('ИмяТаблицы', 'ИмяИндекса') для крупных таблиц.
Замедление операций ввода-вывода или неоптимизированные запросы могут увеличивать время удержания блокировок, что, в свою очередь, может приводить к увеличению блокировок и взаимоблокировок между сеансами 1С. Проверяйте логи SQL Server на наличие сообщений о блокировках. Используйте хранимую процедуру sp_whoisactive или другие инструменты мониторинга для выявления активных блокировок во время выполнения медленных операций.
MAXDOP (Maximum Degree of Parallelism) в SQL Server:
Параметр "Максимальная степень параллелизма" (MAXDOP) в SQL Server часто рекомендуется устанавливать в 1 для систем 1С. Это помогает избежать проблем с параллельным выполнением запросов, которые могут приводить к блокировкам и взаимоблокировкам, особенно на OLTP-нагрузках, характерных для 1С. Убедитесь, что на обоих серверах этот параметр установлен одинаково.
Если программист указывает на громоздкие и тормозные запросы, это требует отдельного внимания. Запросы с большим количеством обращений "через точку" (например, ВТ_ГрафикиДействующиеСУчетомПериодичности.ГруппаНоменклатуры = ВТ_ДоступнаяНоменклатураСклад.Папка.Родитель.Родитель.Родитель.Родитель.Родитель.Родитель.Родитель.Родитель.Родитель) или с использованием ЛюбаяСсылка часто приводят к неоптимальным планам запросов в SQL Server. Мы рекомендуем переписывать такие запросы с использованием временных таблиц, явных соединений и оптимизированных функций для работы с иерархиями. Также можно рассмотреть выполнение запросов в привилегированном режиме, если это допустимо.
Помимо основных причин, которые мы рассмотрели, существует ряд других факторов, которые могут влиять на производительность 1С и SQL Server. Проанализируем ситуацию с точки зрения общих настроек и лучших практик.
Рассмотрим подробнее следующие аспекты:
В сообществе 1С распространено наблюдение, что некоторые версии платформы (например, 8.3.27.1688, 8.3.27.1719, 8.3.27.1644) могут быть медленнее предыдущих (8.3.27.1606 или 8.3.25.1394). Производительность платформы может меняться от версии к версии из-за изменений во внутреннем устройстве, оптимизаций или, наоборот, появления новых проблем. Мы настоятельно рекомендуем проводить тщательное тестирование на копии базы данных перед обновлением платформы на продуктивных системах. Для оценки производительности можно использовать Тест Гилева (TPC-1C), который позволяет измерить скорость выполнения типовых операций и сравнить ее с эталонными показателями.
Для физических серверов с MS SQL Server и 1С критически важны настройки BIOS/UEFI. Убедитесь, что режим электропитания установлен на "Высокая производительность" (High Performance), а не на "Сбалансированный" (Balanced) или "Энергосберегающий". Также проверьте настройки контроллера дисков (например, режим AHCI для SSD, настройки кэширования RAID-контроллера, если он используется).
Убедитесь, что папки с файлами баз данных SQL Server (.mdf, .ldf), файлами tempdb, а также рабочие каталоги сервера 1С:Предприятие (кластер 1С) и файлы технологического журнала исключены из проверки антивирусным программным обеспечением. Антивирус может значительно замедлять операции ввода-вывода и приводить к блокировкам файлов.
Режим разделения и формат журнала регистрации 1С также могут влиять на производительность. Если журнал регистрации ведется в одном файле и имеет большой объем, это может создавать дополнительную нагрузку на дисковую подсистему. Мы рекомендуем использовать режим разделения журнала регистрации по дням или по размеру, а также рассмотреть возможность вынесения его на отдельный, более быстрый диск.
Убедитесь, что установлены все последние обновления для вашей операционной системы (Windows Server 2022) и SQL Server (2022 Enterprise). Иногда исправления производительности могут быть включены в кумулятивные обновления.
Подведем итог: Проблемы с производительностью в 1С часто имеют комплексный характер. В нашем случае, ключевой причиной оказалось неосторожное использование параметра SCRIPTCIRCREFS в Технологическом журнале 1С. Однако, как мы выяснили, потенциальные проблемы могут скрываться и на более глубоком уровне – в дисковой подсистеме (misaligned log IOs), в конфигурации SQL Server, а также в неоптимизированных запросах и даже в используемой версии платформы 1С. Мы призываем вас подходить к диагностике систем 1С системно, последовательно исключая возможные причины и тщательно проверяя все аспекты работы.