Переход с файловой версии 1С:Предприятие на серверную (MS SQL) часто рассматривается как панацея от «тормозов». Однако на практике пользователи нередко сталкиваются с обратным эффектом: поиск в справочнике «Номенклатура» начинает занимать 30–60 секунд, а процессор сервера загружается до 100% — контролировать нагрузку поможет утилита администрирования сервера и мониторинга фоновых заданий 1С. Разберем подробно, почему так происходит в 1С:Управлении нашей фирмой 3.0, и какие шаги помогут вернуть системе быстродействие.
Проанализируем механику поиска в динамических списках. Когда мы вводим текст в верхнюю строку поиска (так называемый «глобальный поиск» по списку), платформа 1С формирует запрос к SQL Server. Проблема заключается в использовании оператора LIKE с ведущим символом процента: LIKE '%Текст%'. Для SQL-сервера это означает, что он не может использовать обычные индексы для быстрого нахождения строки. Ему приходится выполнять операцию Index Scan или Table Scan — то есть буквально перебирать все десятки тысяч записей в таблице номенклатуры, чтобы найти совпадение внутри строки.
Если при этом используется слабый процессор (например, Intel Pentium G4400 с двумя ядрами), ситуация становится критической. Одно ядро полностью поглощается SQL-запросом, а второе пытается обслужить работу самой платформы 1С и операционной системы. В итоге мы видим полное зависание интерфейса.
Рассмотрим самый быстрый способ облегчить жизнь серверу без глубокого вмешательства в настройки SQL. В 1С:УНФ 3.0 существует возможность переключить режим поиска в конкретной форме — для этого подойдёт расширение для настройки и переопределения поиска в списках 1С. Рассмотрим, как это сделать:
Важный нюанс: Программный (настраиваемый) поиск работает быстрее, так как он часто ограничен только «Наименованием» и «Артикулом». Обычный же поиск пытается искать по всем колонкам, которые выведены в список (включая дополнительные реквизиты, характеристики и представления), что кратно увеличивает нагрузку на rphost и SQL-сервер.
Многие системные администраторы считают, что полнотекстовый поиск (ППД) только мешает, и отключают его. Однако именно ППД призван решать проблему поиска LIKE '%...%'. Если индекс ППД актуален, платформа может использовать его вместо тяжелого SQL-запроса.
Разберем шаги по реанимации полнотекстового поиска:
ОбновлениеИндексаППД и СлияниеИндексаППД должны выполняться регулярно (каждые 1-5 минут).Посмотрим на программный аспект: если мы хотим принудительно обновить индекс через код (например, во внешней обработке), это выглядит так:
ПолнотекстовыйПоиск.УстановитьРежимПереиндексации(РежимПереиндексацииПолнотекстовогоПоиска.Полная);
ПолнотекстовыйПоиск.ОбновитьИндекс(Истина);
Если база работает на MS SQL, «коробочные» настройки сервера часто не подходят для 1С. Выясним, какие параметры критически важны для быстрого поиска.
1. Уровень совместимости (Compatibility Level)
Для новых версий SQL Server (2016, 2017, 2019) оптимизатор запросов может некорректно строить планы для сложных соединений 1С. Рекомендуется установить уровень совместимости 110 (соответствует SQL Server 2012) или 120. Это заставит SQL использовать старый, более предсказуемый для 1С движок генерации планов.
2. Настройка MAXDOP
Параметр Max Degree of Parallelism (MAXDOP) определяет, на сколько ядер SQL может «раскладывать» один запрос. Для 1С на слабых серверах (2-4 ядра) строго рекомендуется установить MAXDOP = 1. Это запретит одному тяжелому поиску занимать все ресурсы процессора, позволяя другим пользователям продолжать работу.
3. Ограничение памяти
Убедимся, что Max Server Memory в настройках SQL Server ограничена так, чтобы оставалось 2–4 Гб для операционной системы и рабочих процессов rphost. Если SQL заберет всю память, начнется свопинг (запись на диск), и поиск замедлится в десятки раз.
SQL Server не может эффективно искать данные, если он «не знает», как они распределены в таблицах. Регулярно выполняем следующие действия через SQL Server Management Studio (SSMS):
Пример SQL-скрипта для быстрого обновления статистики во всей базе:
EXEC sp_updatestats;
Проанализируем поведение пользователей. Часто они ищут данные через общую строку сверху, что заставляет систему искать слово «Шланг» и в наименовании, и в артикуле, и в комментарии. Если приучить персонал использовать Расширенный поиск (вызывается клавишей Alt + F или через значок лупы в шапке колонки), платформа будет строить запрос только по конкретному полю. Это позволяет SQL использовать Index Seek, что происходит практически мгновенно даже на очень больших базах — в качестве альтернативы поможет готовое решение для создания быстрых преднастроенных фильтров в списках 1С.
Медленный поиск в 1С:УНФ на SQL-версии — это чаще всего результат «железа», не соответствующего нагрузке, или некорректных настроек сервера БД. Для исправления ситуации выполним комплекс мер:
MAXDOP = 1 и Compatibility Level = 110 в настройках SQL.Alt+F).Такой системный подход позволит комфортно работать в 1С:УНФ 3.0 даже при наличии десятков тысяч позиций номенклатуры.