Когда пользователи жалуются, что 1С «тормозит», первым решением часто становится добавление оперативной памяти, процессорных ядер или более быстрых дисков. Иногда это помогает, но не отвечает на главный вопрос: какой компонент действительно задерживает конкретную операцию.

Один медленный отчет может упираться в неоптимальный запрос. Проведение документов — в ожидания на блокировках. Утреннее падение скорости — в регламентное задание, резервное копирование или обслуживание индексов. После обновления конфигурации может измениться SQL-план, а после переноса виртуальной машины — появиться конкуренция за процессор или хранилище.

Поэтому оптимизация производительности 1С и Microsoft SQL Server начинается не с изменения параметров, а с измерений. Сначала нужно связать жалобу пользователя с операцией в 1С, запросом в SQL Server и состоянием инфраструктуры в тот же момент. Только после этого можно выбрать решение и проверить его результат.

Почему 1С и SQL Server нужно анализировать вместе

В клиент-серверном варианте пользователь работает не с SQL Server напрямую. Запрос проходит через несколько уровней:

клиент 1С → сервер 1С:Предприятия → Microsoft SQL Server → операционная система → хранилище.

На каждом уровне возможна своя задержка:

Уровень	Что может замедлять работу	Чем подтверждать
Клиент и сеть	высокая задержка, потери пакетов, слабое рабочее место, тяжелая форма	время клиентского и серверного вызова, сетевые метрики, сравнение рабочих мест
Код и конфигурация 1С	запросы в цикле, избыточная выборка, неэффективные соединения, неверная работа с виртуальными таблицами	замер производительности, технологический журнал, анализ кода и текста запроса
Кластер 1С	нехватка памяти рабочих процессов, конкуренция фоновых и пользовательских заданий, неверное распределение сервисов	показатели процессов 1С, консоль администрирования кластера, системный мониторинг
SQL Server	неподходящий план, устаревшая статистика, блокировки, дефицит памяти, ожидания CPU или ввода-вывода	Query Store, планы выполнения, DMV, Extended Events, счетчики производительности
ОС, виртуализация и диски	CPU Ready, swapping, перегруженный datastore, медленный журнал транзакций, конкуренция с резервным копированием	метрики гипервизора, Windows Performance Monitor, задержки файлов SQL Server

Настройка одного уровня не исправляет дефект другого. Быстрый NVMe не устранит запрос, который читает миллионы лишних страниц. Дополнительные ядра не снимут блокировку. А переписывание отчета не поможет, если виртуальная машина регулярно ждет процессорное время на перегруженном хосте.

Сначала зафиксировать проблему, а не впечатление

Фраза «1С стала работать медленно» недостаточна для диагностики. До сбора трассировок нужно описать воспроизводимый сценарий:

1. Какая именно операция выполняется: открытие формы, проведение документа, формирование отчета, закрытие месяца, обмен или фоновое задание.
2. Когда возникает проблема: постоянно, в определенные часы, после обновления или только при одновременной работе нескольких пользователей.
3. Каков фактический результат: операция выполняется 12 секунд вместо обычных 2 или 6 минут вместо 40 секунд.
4. Какой объем данных и период выбран, под каким профилем выполняется операция.
5. Повторяется ли задержка на другом рабочем месте и в тестовой копии базы.

Для бизнес-операций полезно заранее определить целевое время. Иначе после изменений можно сказать лишь, что система «кажется быстрее». Измеримая цель выглядит иначе: например, сократить медианное время открытия отчета с 40 до 10 секунд при тех же параметрах и объеме данных, не ухудшив проведение документов.

Как собрать исходные данные

Нужны синхронные данные с трех сторон: 1С, SQL Server и инфраструктуры. Снимок только одного слоя часто приводит к неверному выводу.

На стороне 1С:Предприятия

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

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

В зависимости от задачи также применяются:

• замер производительности встроенного языка;
• журнал регистрации;
• показатели рабочих процессов и консоль администрирования кластера;
• средства корпоративного инструментального пакета 1С, если они доступны;
• мониторинг процессов rphost, rmngr и связанных системных счетчиков.

Официальная методика 1С отдельно рекомендует сопоставлять показатели процессов платформы с общими счетчиками Windows при анализе аппаратной нагрузки кластера.

На стороне Microsoft SQL Server

Для анализа важны не только «самые долгие запросы», но и частота выполнения, суммарное потребление CPU, логические чтения, записи, ожидания, варианты планов и время появления регрессии.

Query Store хранит историю запросов, планов и статистики выполнения, поэтому особенно полезен, когда проблема возникла после обновления или проявляется периодически. В новых базах SQL Server 2022 он включен по умолчанию, а в более ранних версиях SQL Server может быть выключен. Перед включением нужно определить политику захвата, срок хранения и допустимый объем. Это описано в документации Microsoft по Query Store.

Проверить состояние Query Store в выбранной базе можно read-only запросом:

USE [ИмяИнформационнойБазы];
GO

SELECT
    actual_state_desc,
    desired_state_desc,
    readonly_reason,
    current_storage_size_mb,
    max_storage_size_mb
FROM sys.database_query_store_options;

Запрос ничего не меняет. Для просмотра части диагностических данных учетной записи могут потребоваться права VIEW DATABASE STATE или VIEW SERVER STATE. Использовать для диагностики рабочую учетную запись сервера 1С не следует: доступ лучше выдавать отдельной административной учетной записи по принципу минимальных привилегий.

Дополнительно проверяют:

• фактические и расчетные планы выполнения;
• статистику ожиданий экземпляра и отдельных сеансов;
• блокировки и взаимоблокировки;
• логические и физические чтения;
• ошибки оценки количества строк;
• выдачу памяти запросам и сбросы операций сортировки или хеширования в tempdb;
• историю автоприроста файлов и заполнение журнала транзакций.

Сами по себе типы ожиданий не являются диагнозом. Например, PAGEIOLATCH_* указывает на ожидание чтения страниц, но причиной может быть как медленное хранилище, так и запрос, создающий чрезмерный поток чтения. Microsoft предлагает сопоставлять ожидания, sys.dm_io_virtual_file_stats и счетчики Windows по методике диагностики проблем ввода-вывода.

На уровне ОС и виртуализации

Средняя загрузка CPU за сутки почти бесполезна для расследования пятиминутной задержки. Нужен временной ряд с достаточной детализацией именно за проблемный интервал.

Минимально стоит собирать:

• загрузку CPU и очередь процессора;
• доступную память, paging и потребление памяти процессами SQL Server и 1С;
• задержки чтения и записи по каждому тому, длину очереди и пропускную способность;
• сетевую задержку между сервером 1С и SQL Server;
• для виртуальных машин — CPU Ready, ballooning/swapping, конкуренцию на datastore и соответствие виртуальной NUMA физической архитектуре.

Одинаковые диски в гостевой Windows не всегда означают разные физические ресурсы. Если файлы данных, журнал, tempdb и резервные копии находятся на разных виртуальных томах, но за ними стоит один перегруженный массив, формальное разделение не устраняет конкуренцию.

Что обычно требует оптимизации

1. Запросы и прикладная логика 1С

Если одна операция создает основную нагрузку, начинать следует с нее, а не с глобальной перестройки сервера. В стандартах 1С среди типичных проблем названы запросы в цикле, неэффективные условия, несоответствие индексов условиям запроса и сложные соединения с вложенными или виртуальными таблицами. Для части сценариев более стабильный план дает разбиение задачи на пакетный запрос с временными таблицами. Эти приемы собраны в официальном разделе «Оптимизация запросов».

При разборе медленного запроса проверяют:

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

Дополнительный индекс — не автоматическое решение. Он ускоряет чтение, но занимает место, увеличивает объем резервных копий и создает дополнительную работу при записи. В базе 1С индекс предпочтительно добавлять поддерживаемым способом через метаданные конфигурации или предусмотренный механизм расширения. Прямое изменение схемы SQL нужно отдельно оценивать с точки зрения поддержки и сохранности после реструктуризации базы.

2. Память SQL Server и сервера 1С

SQL Server стремится использовать доступную память для кэша данных и планов. Если параметр max server memory (MB) не ограничен с учетом остальных процессов, операционная система и сервер 1С могут столкнуться с дефицитом памяти. Разработчики 1С прямо указывают, что при совместной установке SQL Server и сервера 1С верхнюю границу памяти SQL необходимо уменьшить на объем, достаточный для платформы 1С. Аналогичный принцип описывает Microsoft: лимит должен оставлять память операционной системе и другим приложениям. См. рекомендации 1С и описание параметров памяти SQL Server.

Универсального значения в процентах нет. Оно зависит от того, совмещены ли роли, сколько баз обслуживает экземпляр, каков пиковый объем рабочих процессов 1С, используется ли антивирус, мониторинг и резервное копирование. Значение выбирают по замерам, а после изменения проверяют давление на память, paging, выдачу памяти запросам и время пользовательских операций.

Текущие параметры можно посмотреть без изменения конфигурации:

SELECT
    name,
    value_in_use
FROM sys.configurations
WHERE name IN
(
    'max server memory (MB)',
    'max degree of parallelism',
    'cost threshold for parallelism'
)
ORDER BY name;

3. Файлы базы, журнал и tempdb

Файлы базы нужно заранее размещать и увеличивать с учетом реального темпа роста. Автоприрост остается страховочным механизмом, а не способом штатного управления емкостью. Слишком маленькие приращения создают множество событий роста, а слишком большие могут надолго занять дисковую подсистему и неожиданно исчерпать место. Microsoft рекомендует подбирать размер приращения по нагрузке и контролировать последствия, а не оставлять параметры без наблюдения: autogrow и autoshrink в SQL Server.

Регулярный SHRINK не является обслуживанием производительности. Он перемещает страницы, может усиливать фрагментацию и часто приводит к повторному росту того же файла. Уменьшение оправдано как отдельная операция после подтвержденного разового освобождения большого объема и с планом последующего обслуживания.

Для tempdb важны не только быстрые диски, но и правильный размер, предсказуемый рост и отсутствие конкуренции за размещение страниц. При подтвержденной allocation contention Microsoft рекомендует начинать с нескольких одинаковых по размеру файлов данных — до одного файла на логический процессор, но не более восьми на первом этапе. Если проблема сохраняется, файлы добавляют группами и снова измеряют результат. Это не означает, что любой сервер 1С автоматически нуждается в восьми файлах: сначала нужно подтвердить характер ожиданий. См. рекомендации Microsoft по снижению contention в tempdb.

Instant File Initialization ускоряет создание и рост файлов данных SQL Server. Включать эту возможность следует осознанно, с учетом версии SQL Server, прав учетной записи службы и требований безопасности. Подробности приведены в документации Microsoft.

4. Статистика и обслуживание индексов

Оптимизатор SQL Server использует статистику для оценки количества строк и выбора плана. После крупных загрузок, обменов или существенного изменения распределения данных автоматического обновления может оказаться недостаточно для конкретного запроса. Но обновлять всю статистику с максимальной выборкой и перестраивать все индексы каждую ночь — тоже неверная стратегия.

Обслуживание должно учитывать размер объекта, плотность страниц, реальное использование индекса, стоимость операции, объем журнала и окно обслуживания. Microsoft отдельно предупреждает, что перестроение индексов потребляет CPU, ввод-вывод и журнал транзакций и способно ухудшить рабочую нагрузку. Практические критерии описаны в материалах по обслуживанию индексов и статистике SQL Server.

5. Параллелизм

Параметры MAXDOP и cost threshold for parallelism часто меняют по готовому рецепту, не учитывая топологию CPU и характер запросов. Это рискованно. Слишком высокий параллелизм позволяет одному тяжелому запросу занять много рабочих потоков; слишком жесткое ограничение может замедлить отчеты и регламентные операции.

Microsoft предлагает выбирать MAXDOP с учетом количества логических процессоров и NUMA, а затем проверять его на реальной нагрузке. Параметр является расширенной настройкой и не должен изменяться без исходных и повторных замеров. Актуальная таблица рекомендаций приведена в документации Microsoft по MAXDOP.

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

6. Блокировки и длительность транзакций

Если операция быстро выполняется в тестовой базе одним пользователем, но нестабильна в рабочее время, нужно проверять конкуренцию. Признаками могут быть большой разброс длительности, тайм-ауты, конфликты управляемых блокировок и ожидания LCK_M_* в SQL Server.

Причиной бывает не только «чужая блокировка». Неоптимальный запрос дольше удерживает ресурсы и блокирует больший объем данных. Длинная транзакция, проведение большого пакета документов, обмен или фоновое задание способны расширить область проблемы. Разработчики 1С рассматривают связь запросов, прикладной логики и избыточных блокировок в методических рекомендациях.

Важно фиксировать граф блокировки и тексты участвующих запросов во время события. Снимок через несколько минут после завершения проблемы уже не покажет ее причину.

Пример: что можно понять из одного точного замера

Рассмотрим обезличенную диагностическую картину:

• отчет выполняется около 370 секунд;
• основной SELECT занимает не менее 355 секунд;
• процессорное время запроса — около 339 секунд;
• выполнено примерно 23,46 млн логических чтений;
• активных блокировок во время замера не зафиксировано.

Эти значения еще не доказывают конкретную причину, но резко сужают поиск. Почти все время операции приходится на один SQL-запрос. Высокое процессорное время и количество логических чтений заставляют в первую очередь анализировать способ доступа к данным и план выполнения, а не перезапускать службы или немедленно добавлять оперативную память.

Логические чтения — это обращения к страницам в буферном кэше SQL Server, а не обязательно физические операции с диском. Поэтому число 23,46 млн само по себе не доказывает проблему хранилища. Оно показывает объем работы, которую запрос потребовал от SQL Server.

Рациональная последовательность в таком случае:

1. Получить фактический план выполнения именно медленного варианта запроса.
2. Сопоставить расчетное и фактическое количество строк по ключевым операторам.
3. Найти таблицы и операции с наибольшим числом чтений.
4. Проверить предикаты, соединения, актуальность статистики и наличие поддерживаемых индексов.
5. Проверить операции сортировки и хеширования на сброс в tempdb и достаточность memory grant.
6. Повторить исходный сценарий после одного контролируемого изменения.

Отсутствие блокировок относится только к конкретному интервалу замера. Оно не исключает периодические блокировки в другое время, но позволяет не делать их основной гипотезой для зафиксированного запуска.

Практический порядок оптимизации

Рабочий процесс удобно строить короткими итерациями.

Шаг 1. Зафиксировать исходное состояние

Сохранить версии платформы, конфигурации и SQL Server, параметры виртуальной машины, настройки памяти и параллелизма, размеры файлов, расписание регламентных заданий и резервного копирования. Обязательно зафиксировать время контрольных операций до изменений.

Шаг 2. Поймать проблему одновременно на всех уровнях

Записать точное время и пользователя, собрать целевой технологический журнал, SQL-диагностику и метрики ОС или гипервизора. Часы на серверах должны быть синхронизированы, иначе события будет трудно сопоставить.

Шаг 3. Классифицировать узкое место

Нужно ответить, где проходит основное время:

• внутри кода 1С;
• в SQL-запросе;
• в ожидании блокировки;
• в очереди CPU;
• в ожидании чтения или записи;
• в дефиците памяти;
• в сетевом обмене;
• в конкуренции фоновых процессов.

Шаг 4. Сформулировать одну проверяемую гипотезу

Например: «задержка вызвана неверной оценкой количества строк после массовой загрузки» или «журнал транзакций конкурирует с резервным копированием за один datastore». Формулировка «SQL Server плохо настроен» не является проверяемой гипотезой.

Шаг 5. Проверить изменение на копии или в контролируемом окне

До изменения нужны резервная копия, способ отката и понимание влияния на поддержку 1С. Для параметров экземпляра SQL Server следует учитывать все размещенные базы, а не только одну информационную базу.

Шаг 6. Повторить тот же тест

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

Шаг 7. Закрепить результат мониторингом

После оптимизации следует сохранить базовый профиль системы и настроить наблюдение за длительными операциями, ошибками, блокировками, свободным местом, ростом файлов, резервным копированием и ресурсами хоста. Без базовой линии очередная деградация снова начнется с субъективного «вчера было быстрее».

Что не стоит делать без диагностики

• Ежедневно перезапускать SQL Server или сервер 1С. Это временно очищает часть состояния и скрывает накопительный эффект, но уничтожает диагностические данные и не устраняет причину.
• Очищать кэш планов целиком. Операция влияет на все базы экземпляра и создает волну повторных компиляций. Она допустима только в обоснованном сценарии с оценкой последствий.
• Перестраивать все индексы по расписанию. Такая работа создает нагрузку, генерирует журнал и может конкурировать с пользователями, не принося заметной пользы небольшим или редко используемым объектам.
• Регулярно выполнять SHRINK. Повторное уменьшение и рост файлов обычно увеличивают объем лишней работы.
• Копировать настройки MAXDOP, памяти и tempdb с другого сервера. Одинаковое число пользователей не означает одинаковую конфигурацию, размер базы, аппаратную топологию и профиль запросов.
• Сразу покупать оборудование. Апгрейд оправдан, когда измерения показывают устойчивый дефицит ресурса после устранения явных дефектов запросов и конфигурации.
• Менять несколько параметров одновременно. В этом случае невозможно доказать, что именно помогло, и сложнее безопасно откатить изменение.

Как выглядит результат нормального аудита производительности

Полезный отчет не заканчивается фразой «нужно добавить RAM». Он должен содержать:

• перечень проблемных пользовательских операций и исходное время;
• доказательства по каждому узкому месту: события 1С, запросы, планы, ожидания и инфраструктурные метрики;
• разделение причин и сопутствующих факторов;
• приоритет действий по эффекту, риску и трудоемкости;
• план тестирования и отката;
• повторные измерения после изменений;
• рекомендации по постоянному мониторингу и предотвращению регрессии.

Для бизнеса это дает понятный выбор. Иногда достаточно исправить один отчет. Иногда требуется пересмотреть регламентные задания или обслуживание SQL Server. В других случаях измерения действительно подтверждают необходимость разнести сервер 1С и СУБД, заменить хранилище или добавить вычислительные ресурсы. Главное — расходы опираются на выявленную причину, а не на предположение.

Вывод

Оптимизация Microsoft SQL Server и сервера 1С:Предприятия — это не набор универсальных параметров. Результат дает последовательность: воспроизвести проблему, собрать синхронные данные, определить уровень задержки, изменить один фактор и повторить измерение.

Если 1С периодически зависает, отчеты выполняются несколько минут, проведение документов замедляется под нагрузкой или проблема появилась после обновления, начинать стоит с диагностики. Аудит позволяет отделить дефекты запросов и блокировки от нехватки ресурсов и только после этого составить безопасный план оптимизации.