Как ускорить работу 1С 8.3 на SQL Server и устранить зависания системы?

← На главную

Проблема производительности 1С:Предприятие в связке с Microsoft SQL Server является одной из наиболее часто обсуждаемых. Зачастую пользователи жалуются на «тормоза» при проведении документов или формировании отчетов, хотя серверные мощности кажутся избыточными. В этой статье мы подробно разберем, как выявить узкие места и какие настройки необходимо выполнить для достижения максимальной отзывчивости системы.

Анализируем настройки SQL Server для работы с 1С

Первым делом проанализируем настройки самого сервера баз данных. Часто стандартные настройки SQL Server «из коробки» не подходят для специфики работы 1С, которая генерирует огромное количество мелких запросов. Рассмотрим критически важные параметры:

Max Degree of Parallelism (MAXDOP). Разберем этот параметр. Он определяет количество процессоров, используемых для выполнения одного запроса. Для 1С рекомендуется устанавливать значение 1 (отключить параллелизм для одного запроса) или, в крайнем случае, от 2 до 4, чтобы тяжелые отчеты не блокировали работу всей базы.
Cost Threshold for Parallelism. Если мы решили оставить параллелизм, увеличим порог стоимости с 5 до 50. Это заставит SQL Server использовать параллелизм только для действительно тяжелых задач.
Max Server Memory. Выясним причину утечек памяти: если не ограничить SQL Server, он заберет всю доступную оперативную память, не оставив ресурсов для rphost (процессов 1С). Оставим минимум 4-8 ГБ для операционной системы и нужд сервера приложений.

Оптимизация кода запросов: избавляемся от вложенных запросов

Посмотрим на пример типичной ошибки программиста 1С — использование вложенных запросов в условии ГДЕ. Это заставляет SQL-оптимизатор строить неоптимальные планы. Заменим их на временные таблицы. Проанализируем ситуацию на примере:


// Неоптимальный запрос
ВЫБРАТЬ
    Продажи.Номенклатура,
    Продажи.Количество
ИЗ
    РегистрНакопления.Продажи КАК Продажи
ГДЕ
    Продажи.Номенклатура В (ВЫБРАТЬ Номенклатура ИЗ Справочник.Номенклатура ГДЕ Тип = &Тип)

Рассмотрим более эффективный вариант с использованием объекта МенеджерВременныхТаблиц. Мы сначала отберем нужные данные во временную таблицу, проиндексируем их, а затем соединим с основной таблицей. Это позволит SQL Server использовать Index Seek вместо Index Scan.


МенеджерВТ = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;

Запрос.Текст = 
"ВЫБРАТЬ
|   Номенклатура.Ссылка КАК Ссылка
|ПОМЕСТИТЬ ВТ_НужнаяНоменклатура
|ИЗ
|   Справочник.Номенклатура КАК Номенклатура
|ГДЕ
|   Номенклатура.Тип = &Тип
|ИНДЕКСИРОВАТЬ ПО
|   Ссылка;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|   Продажи.Номенклатура,
|   Продажи.Количество
|ИЗ
|   РегистрНакопления.Продажи КАК Продажи
|ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_НужнаяНоменклатура КАК ВТ_НужнаяНоменклатура
|ПО Продажи.Номенклатура = ВТ_НужнаяНоменклатура.Ссылка";

Запрос.УстановитьПараметр("Тип", НужныйТип);
Результат = Запрос.Выполнить();

Работа с блокировками данных

Часто причиной медленной работы являются не сами запросы, а ожидания на блокировках. В платформе 1С 8.3 по умолчанию используется управляемый режим блокировок. Проанализируем, как правильно устанавливать блокировку перед записью данных, чтобы не возникало ошибки Конфликт блокировок при выполнении транзакции.

Разберем по шагам использование объекта БлокировкаДанных:

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


Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Склад", ВыбранныйСклад);
Блокировка.Заблокировать();

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

Регламентные операции на SQL Server

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

Обновление статистик (Update Statistics). Помогает оптимизатору SQL правильно оценивать количество строк и выбирать верный план запроса. Рекомендуется выполнять ежедневно.
Реорганизация и реиндексация (Index Rebuild/Reorganize). Устраняет фрагментацию данных. Если фрагментация более 30%, используем Rebuild.
Очистка процедурного кэша. Иногда полезно сбрасывать кэш планов, если SQL Server зациклился на неудачном плане выполнения.

Для автоматизации этих процессов лучше всего использовать SQL Server Agent и настроенные Maintenance Plans (планы обслуживания). В 1С также есть встроенные средства для управления некоторыми из этих процессов через Консоль администрирования кластера.

Заключение и рекомендации

Подводя итог нашему анализу, отметим, что скорость работы 1С зависит от синергии трех факторов: качественного кода (использование ВременныеТаблицы, отсутствие запросов в циклах), правильных настроек СУБД (MAXDOP, память) и регулярного обслуживания базы данных. Мы рекомендуем начинать оптимизацию с замера производительности встроенным инструментом Оценка производительности (по методике APDEX), чтобы четко понимать, какие именно операции являются наиболее критичными для пользователей.

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