Медленная 1С губит продажи: когда апгрейд сервера лишь иллюзия

1 сентября 2026 · infolimp.ru

Иллюзия апгрейда: почему новый сервер не помогает

Когда после замены сервера скорость не растёт, а иногда падает, специалист 1С сталкивается с классической ловушкой: проблема не в вычислительной мощности, а в логике блокировок. Новый CPU быстрее обрабатывает запросы, но если каждый запрос ждёт освобождения ресурса — прирост нулевой. Более того, на мощном сервере увеличивается конкуренция за блокировки: потоки выполняются быстрее, чаще сталкиваются, и время ожидания растёт.

Узкое место не в CPU, а в блокировках

Рассмотрим типичный сценарий: проведение документа с длинной транзакцией, внутри которой — цикл с отдельными запросами к регистрам. Каждый запрос захватывает блокировку на запись. Если одновременно работают несколько пользователей, они блокируют друг друга, и система встаёт.

// НЕПРАВИЛЬНО: длинная транзакция с множеством мелких запросов
НачатьТранзакцию();
Попытка
    Для Каждого Строка Из ТаблицаТоваров Цикл
        Запрос = Новый Запрос;
        Запрос.Текст = 
        "ВЫБРАТЬ
        |   Остатки.КоличествоОстаток
        |ИЗ
        |   РегистрНакопления.ТоварыНаСкладах.Остатки(&Склад, &Номенклатура) КАК Остатки";
        Запрос.УстановитьПараметр("Склад", Строка.Склад);
        Запрос.УстановитьПараметр("Номенклатура", Строка.Номенклатура);
        Результат = Запрос.Выполнить().Выбрать();
        // ... обработка ...
        // Запись движения
        Движение = РегистрыНакопления.ТоварыНаСкладах.СоздатьДвижение();
        Движение.Записать(Истина); // блокировка на запись
    КонецЦикла;
    // ... ещё операции ...
    ЗафиксироватьТранзакцию();
Исключение
    ОтменитьТранзакцию();
    ЗаписьЖурналаРегистрации("Ошибка", УровеньЖурналаРегистрации.Ошибка,, , КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;

Каждый вызов Записать(Истина) внутри цикла — это монопольная блокировка на время записи. Если в системе 10 пользователей, каждый держит свою транзакцию, они выстраиваются в очередь. Апгрейд сервера не сократит время ожидания — он лишь ускорит выполнение самого запроса, но блокировки останутся.

Ключевой тезис: Апгрейд сервера без рефакторинга кода — это как замена двигателя в машине с заблокированными колёсами. Быстрее не поедете.

Как медленная 1С убивает продажи: реальные сценарии

Задержки в 1С напрямую влияют на выручку. Рассмотрим два типовых случая.

Зависание при проведении документа

Менеджер оформляет заказ клиента. При проведении документа система «задумывается» на 10–15 секунд. Клиент на линии теряет терпение и уходит. Если таких заказов 50 в день — потери очевидны. Причина часто в том, что при проведении выполняется пересчёт остатков через виртуальную таблицу Остатки без фильтра по периоду, что приводит к полному сканированию таблицы движений.

// НЕПРАВИЛЬНО: запрос без фильтра по периоду
Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
|   ТоварыОстатки.Номенклатура,
|   ТоварыОстатки.КоличествоОстаток
|ИЗ
|   РегистрНакопления.Товары.Остатки КАК ТоварыОстатки"; // нет условий — полное сканирование

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

Торговые точки: потеря клиентов из-за ожидания

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

Диагностика: найти истинную причину тормозов

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

• Технологический журнал (ТЖ) — настройте запись событий DBLOCK и TTIMEOUT. Это покажет, какие транзакции блокируют других.
• Анализ производительности (встроенный) — включите замеры и посмотрите на «тяжёлые» вызовы.
• Стандартные отчёты «Анализ производительности» — они покажут, какие запросы выполняются дольше всего.

Не верьте глазам: если после апгрейда сервера время выполнения запроса упало с 5 до 2 секунд, но блокировки остались — общее время ожидания пользователей может даже вырасти из-за возросшей конкуренции.

Что делать прямо сейчас: план действий

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

1. Проверьте длинные транзакции. Найдите в коде места, где НачатьТранзакцию() и ЗафиксироватьТранзакцию() находятся далеко друг от друга. Разбейте на более мелкие, если это возможно по бизнес-логике.
2. Оптимизируйте запросы к виртуальным таблицам. Всегда добавляйте условия по измерениям и периодам. Избегайте ВЫБРАТЬ * без отборов.
3. Используйте пакетные операции. Вместо цикла с записью каждого движения — формируйте набор записей и записывайте одним набором через Записать(Ложь) (не монопольно) или через НаборЗаписей.
4. Настройте изоляцию транзакций. Для отчётов используйте уровень READ UNCOMMITTED (через УстановитьИзоляциюТранзакции), чтобы не блокировать оперативные данные.
5. Мониторьте блокировки. Включите ТЖ с событиями DBLOCK и анализируйте, какие объекты конфликтуют.

Предупреждение: Не пытайтесь «ускорить» 1С установкой SSD или увеличением RAM, не выяснив причину тормозов. Часто это приводит к тому, что проблема маскируется, а затем проявляется с новой силой при росте нагрузки.

Типичные ошибки при оптимизации

Даже опытные специалисты совершают одни и те же ошибки. Вот три самые распространённые:

• Ошибка 1: «Поставим индекс — всё заработает». Индексы помогают только при поиске по конкретным полям. Если запрос использует функцию в условии (ВЫБРАТЬ ... ГДЕ НАЧАЛОПЕРИОДА(Дата, МЕСЯЦ) = ...), индекс не сработает.
• Ошибка 2: «Увеличим кэш — и всё полетит». Кэш 1С не ускоряет запросы, которые каждый раз выполняются заново. Он лишь сохраняет результаты редких операций. Основная нагрузка — на SQL Server.
• Ошибка 3: «Перепишем всё на фоновые задания». Фоновые задания не снимают блокировки, они просто переносят проблему на другое время. Если задание держит транзакцию, оно всё равно блокирует других.

Помните: апгрейд сервера — это последнее, что стоит делать. Сначала — код, потом — настройки, и только затем — железо.