← На главную

Сопровождение высоконагруженных информационных систем на базе платформы 1С:Предприятие и СУБД MS SQL Server требует непрерывного контроля за производительностью. При работе с масштабными базами данных администраторы и эксперты сталкиваются с необходимостью отслеживать узкие места системы, анализировать неоптимальные запросы и предотвращать эскалацию блокировок. Проанализируем, почему универсальные сторонние разработки в виде исполняемых файлов не пользуются популярностью на продуктивных серверах, и разберем проверенные инструменты и практические методики оптимизации связки 1С и MS SQL Server.

Почему сторонние закрытые утилиты не применяются на продуктивных серверах

При поиске решений для отлова узких мест разработчики иногда создают собственные утилиты и предлагают их сообществу. Однако администраторы баз данных (DBA) и эксперты 1С практически никогда не запускают сторонние исполняемые файлы (.exe) с закрытым кодом на боевых серверах.

Разберем основные причины такого поведения:

1. Безопасность и риски отказа: Запуск стороннего исполняемого файла с правами администратора на продуктивном сервере несет неуправляемые риски — от утечки конфиденциальной информации до падения СУБД или повреждения данных.
2. Избыточная нагрузка на диски и CPU: Неоптимизированный мониторинг, работающий 24/7, может сам стать причиной падения производительности, генерируя гигабайты трассировок и замедляя рабочие транзакции.
3. Требование к прозрачности: Специалисты предпочитают либо решения от известных вендоров с гарантией качества, либо полностью открытые скрипты, логику работы которых можно проверить до запуска.

Проверенные инструменты мониторинга 24/7

Рассмотрим штатные и специализированные решения, которые применяются для круглосуточного отслеживания состояния высоконагруженных баз данных без создания критической нагрузки на сервер.

1. 1С:КИП и ЦУП (Центр управления производительностью)

Типовой Корпоративный инструментальный пакет (КИП) от компании 1С включает инструмент ЦУП, предназначенный для анализа узких мест многопользовательской трехзвенной архитектуры. Он позволяет связывать задержки на уровне платформы 1С с конкретными вызовами и ожиданиями на уровне СУБД. Однако при постоянной работе ЦУП может накапливать огромные объемы данных, поэтому для режима 24/7 его часто настраивают точечно или включают по мере необходимости.

2. MS SQL Query Store (Хранилище запросов)

Начиная с MS SQL Server 2016, в СУБД встроен мощный механизм Query Store. Он автоматически собирает историю выполнения запросов, планов и статистики ресурсов (CPU, Memory, I/O). Это позволяет легко находить запросы с регрессией производительности, сравнивать разные планы выполнения и фиксировать заведомо оптимальный план без изменения кода 1С.

3. Data Collection и Extended Events

Встроенный механизм Data Collection в MS SQL Server собирает основные метрики СУБД в системную базу данных. Для постоянного фиксатора проблемных запросов вместо тяжелого SQL Profiler применяют Extended Events (Расширенные события). Настройка асинхронной фиксации событий (например, sql_statement_completed или xml_deadlock_report) с порогом по длительности создает нагрузку на CPU в пределах 1–2%, что делает его безопасным для применения 24/7.

4. Профилированный Технологический журнал 1С

Для непрерывного мониторинга на стороне 1С настраивают сбор Технологического журнала (ТЖ) с жесткой фильтрацией. Чтобы не переполнять диск, собирают только события ошибок и долгих операций (EXCP, TLOCK, TDEADLOCK, DBMSSQL) с ограничением по длительности (например, duration > 5000000 микросекунд).

5. Сторонние специализированные сервисы

Для глубокого анализа применяются зарекомендовавшие себя коммерческие и облачные системы, такие как PerfExpert или специализированные сервисы анализа производительности 1С, которые работают через безопасный сбор метрик без вмешательства в структуру СУБД.

Ключевые причины проблем производительности в связке 1С и MS SQL

Выясним, с какими специфическими техническими проблемами наиболее часто сталкиваются высоконагруженные системы 1С на базе MS SQL Server:

1. Parameter Sniffing (сниффинг параметров): Платформа 1С формирует динамические параметризованные запросы с помощью sp_executesql. Оптимизатор MS SQL компилирует план при первом вызове. Если данные в таблицах распределены неравномерно, закэшированный план может оказаться крайне неэффективным для других параметров.
2. Неактуальность статистик: Автоматическое обновление статистик в MS SQL запускается только при изменении порядка 20% строк таблицы. На таблицах с миллионами записей оптимизатор начинает ошибаться в оценке количества строк (Cardinality Estimation), меняя эффективный Index Seek на полное сканирование Index Scan.
3. Конкуренция за TempDB: Интенсивное использование временных таблиц в запросах 1С создает высокую нагрузку на системные страницы TempDB, приводя к ожиданиям типа PAGELATCH_UP и PAGELATCH_EX.
4. Влияние механизма RLS и режима блокировок: Разграничение прав на уровне записей (RLS) усложняет текст запроса, а автоматический режим блокировок транслирует жесткие уровни изоляции (Repeatable Read / Serializable), вызванная эскалацией блокировок и взаимными блокировками (Deadlock).

Оптимальные настройки MS SQL Server и регламентные процедуры

Проанализируем комплекс обязательных настроек сервера СУБД для обеспечения высокой скорости работы 1С:

1. Уровень изоляции RCSI: В режиме управляемых блокировок 1С необходимо включать параметр READ_COMMITTED_SNAPSHOT (RCSI). Это позволяет запросам чтения брать данные из версионного хранилища TempDB без наложения блокировок чтения, исключая конфликты между считывающими и записывающими транзакциями.
2. Конфигурация TempDB: Файлы данных TempDB создаются в количестве, равном числу физических ядер процессора (но не более 8), с одинаковым начальным размером и шагом авторасширения. На версиях MS SQL до 2016 года обязательно включаются флаги трассировки TF 1117 (равномерное расширение файлов) и TF 1118 (выделение полных экстентов).
3. Настройка параллелизма: Ограничивают параметр MAXDOP (максимальное число ядер на один запрос) и существенно повышают порог стоимости параллелизма Cost Threshold for Parallelism со стандартного значения 5 до 50 и выше. Это защищает систему от распараллеливания коротких транзакций 1С.
4. Мгновенная инициализация файлов: Службе MS SQL назначается право Perform Volume Maintenance Tasks (Instant File Initialization), что позволяет мгновенно выделять дисковое пространство под файлы базы без их заполнения нулями.
5. Автоматизация обслуживания: Для обслуживания индексов и статистик рекомендуется использовать проверенный комплекс скриптов Ola Hallengren Maintenance Solution, который выполняет умную дефрагментацию и обновление статистик с учетом актуальной нагрузки.

Таким образом, полноценное сопровождение высоконагруженной системы 1С базируется на сочетании штатных механизмов СУБД, профилированного ТЖ и правильной тонкой настройки параметров MS SQL Server.