Почему 1С тормозит избирательно у разных пользователей и как это исправить

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

Анализ ситуации: почему тормоза привязаны к логину

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

Основными факторами здесь выступают:

1. Локальный кэш конфигурации: временные файлы, которые хранятся в профиле пользователя Windows.
2. Настройки в самой базе данных: история отборов, сохраненные настройки отчетов и форм, которые хранятся в системных таблицах.
3. План выполнения запроса на SQL-сервере: так называемый Parameter Sniffing.

Шаг 1. Глубокая очистка кэша: не всё так просто

Первое, что мы обычно делаем — чистим временные папки AppData\Local\1C и AppData\Roaming\1C. Однако при работе в клиент-серверном варианте (особенно в сильно доработанных конфигурациях типа УТ 10.3 + CRM) кэш может обновляться некорректно. Разберем, как правильно подойти к этой процедуре.

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

Шаг 2. Очистка пользовательских настроек внутри базы данных

Проанализируем важный момент: 1С хранит настройки форм, списков и отчетов непосредственно в таблицах SQL (например, в системной таблице ConfigSave или настройках пользователя). Если пользователь в течение долгого времени сохранял сотни вариантов отчетов или у него накопилась огромная история поисковых запросов в динамических списках, система будет тратить значительное время на чтение этого «мусора» при каждом открытии формы.

Рассмотрим алгоритм действий для сброса настроек:

1. Зайдем в базу под полными правами.
2. Откроем обработку «Управление настройками пользователей» (в УТ 10.3 она находится в меню «Сервис»).
3. Выберем проблемного пользователя и полностью очистим его настройки окна, настройки форм и настройки отчетов.

Часто именно этот шаг решает проблему «10-секундного открытия формы», так как 1С перестает пытаться восстановить битые или слишком объемные двоичные данные настроек из базы.

Шаг 3. Решение проблемы Parameter Sniffing на SQL Server

Если поиск по артикулу «вчера летал, а сегодня тормозит у всех», мы имеем дело с типичной проблемой переиспользования плана запроса (Parameter Sniffing). Проанализируем ситуацию: SQL-сервер строит план выполнения запроса на основе первого запуска. Если первый запуск был выполнен с «неудачным» параметром, SQL запоминает этот медленный план для всех последующих вызовов.

Для исправления ситуации выполним следующие действия на стороне SQL-сервера:

1. Обновление статистики: это заставит SQL пересмотреть распределение данных в индексах.
2. Очистка процедурного кэша: удаление старых планов выполнения.

Рекомендуется использовать следующий скрипт для регламентного обслуживания (выполняет админ базы данных):

EXEC sp_updatestats;
DBCC FREEPROCCACHE;

После выполнения этих команд скорость поиска обычно восстанавливается мгновенно.

Шаг 4. Оптимизация кода поиска в доработанных формах

В сильно измененных конфигурациях (как в случае с гибридом УТ и CRM) стандартные механизмы поиска могут быть перекрыты программным кодом. Разберем пример ситуации, когда поиск по артикулу в табличном поле начинает тормозить из-за неоптимальных запросов.

Если мы видим, что стандартный ВводПоСтроке работает медленно, проанализируем возможность замены прямого поиска на использование условий ПОДОБНО с индексированными полями. Посмотрим на пример кода, который может ускорить работу, если добавить его в обработчик поиска:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ 100
    |   Номенклатура.Ссылка,
    |   Номенклатура.Артикул
    |ИЗ
    |   Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |   Номенклатура.Артикул ПОДОБНО &ТекстПоиска + ""%""";

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

Важно помнить, что использование процента "%" в начале строки (например, "%"+ТекстПоиска) делает невозможным использование индексов, и система будет выполнять полное сканирование таблицы (Index Scan или Table Scan), что и приводит к многоминутным ожиданиям.

Шаг 5. Сетевые настройки и аппаратное ускорение

Выясним причину, по которой админ утверждает, что «сеть в порядке», а 1С всё равно тормозит. Существуют специфические настройки сетевых карт, такие как Receive Segment Coalescing (RSC) и Large Send Offload (LSO). Эти технологии отлично работают при передаче больших файлов, но могут «склеивать» или задерживать мелкие пакеты данных, которыми обмениваются 1С и SQL-сервер.

Попробуем выполнить следующие действия:

1. На сервере и на проблемном компьютере зайдем в настройки сетевого адаптера.
2. В разделе «Дополнительно» найдем параметры, связанные с IPv4 Checksum Offload, Large Send Offload и RSC.
3. Переведем их в состояние Disabled (Выключено).

Это часто устраняет микрозадержки, которые в сумме дают те самые 10–15 секунд при открытии форм.

Шаг 6. Проверка полнотекстового поиска

В платформе 1С 8 существует механизм полнотекстового поиска (ПП). Если индекс ПП поврежден или находится в процессе масштабного обновления, это может блокировать работу пользователей при вводе данных в любые поля. Проанализируем состояние индекса через «Консоль администрирования» или программно. Если полнотекстовый поиск не критичен для работы сотрудников, его стоит временно отключить, чтобы проверить, исчезнут ли тормоза.

Подводя итог, отметим, что решение подобных проблем всегда требует комплексного подхода: от очистки настроек конкретного пользователя до глубокого тюнинга SQL-сервера и сетевого стека.