От чего зависит производительность 1С

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

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

Аппаратные ресурсы сервера и СУБД

В клиент-серверном режиме основная нагрузка ложится на сервер СУБД и сервер приложений 1С. Ключевой ресурс для базы данных — быстрые диски: операции записи журнала транзакций и чтение данных чувствительны к задержкам. Медленные HDD вместо SSD — одна из самых частых причин «тормозов» при проведении документов и формировании отчётов.

Оперативная память влияет на то, сколько данных СУБД может держать в кэше. Если рабочий набор данных не помещается в память, система постоянно обращается к диску, и скорость падает. Процессор важен для расчётов и обработки запросов, но на практике CPU редко становится первым узким местом — обычно раньше упираются в диски или память.

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

Настройки СУБД и их влияние

Даже мощный сервер не спасёт, если СУБД настроена по умолчанию. Для MS SQL Server, PostgreSQL и других поддерживаемых СУБД важны: объём выделенной памяти, параметры журнала транзакций, модель восстановления базы, настройки параллелизма и регулярность обслуживания индексов и статистики.

Устаревшая статистика заставляет оптимизатор запросов выбирать неудачные планы выполнения, из-за чего один и тот же запрос может выполняться секунды вместо миллисекунд. Фрагментированные индексы увеличивают количество операций чтения. Обе проблемы решаются регламентным обслуживанием: обновлением статистики и реорганизацией индексов.

Также критично, где физически расположены файлы данных и журнал транзакций. Размещение их на одном медленном диске создаёт конкуренцию за ресурсы ввода-вывода. Рекомендуемая практика — разносить данные и журнал на разные физические устройства.

Качество кода и запросов конфигурации

Значительная часть проблем производительности заложена в самой конфигурации. Типичные источники: запросы в цикле, обращение к базе через точку от объекта, получение лишних данных («выбрать всё, а потом отфильтровать в коде»), отсутствие индексов по полям отборов, избыточные соединения таблиц.

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

Найти такие места помогает замер производительности (встроенный инструмент конфигуратора) и технологический журнал с настройкой сбора событий DBMSSQL/DBPOSTGRS и TLOCK. Для типовых конфигураций существует Центр управления производительностью, который агрегирует статистику по медленным операциям.

Объём данных и структура базы

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

Что помогает справляться с ростом объёма: своевременная свёртка итогов по закрытым периодам, установка даты запрета изменения данных, архивация старых данных в отдельную базу, использование итогов регистров вместо расчёта «на лету» за всю историю.

Ещё один фактор — версионирование и журнал регистрации без ограничений. Если журнал регистрации никогда не сокращается, он разрастается и замедляет работу. Регулярная настройка сокращения журнала — простая мера с заметным эффектом на больших базах.

Сеть и клиентская часть

Между клиентом, сервером приложений и СУБД постоянно идёт обмен данными. Если канал между клиентом и сервером имеет высокие задержки (например, работа через медленный VPN или нестабильный Wi-Fi), пользователь ощущает это как «тормоза 1С», хотя сервер работает нормально. Тонкий клиент передаёт меньше данных, чем толстый, и лучше подходит для медленных каналов.

На клиентском компьютере влияют: разрядность клиента и доступная память (большие отчёты могут упираться в лимит памяти 32-битного клиента), антивирус, проверяющий файлы базы и платформы в реальном времени, а также скорость диска, если используется файловый режим.

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

Маршрут решения

Как выбрать действие

Медленно у всех пользователей и на сервере тожеПроверяйте СУБД: статистику, индексы, дисковую подсистему, долгие запросы в техножурнале

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

Медленно только при одновременной работе нескольких пользователейИщите избыточные блокировки: события TLOCK в техножурнале, deadlock-логи СУБД

Медленно только в конкретном отчёте или документеАнализируйте запросы этого объекта через замер производительности и план запроса

Регламентные задания и фоновые процессы

Фоновые и регламентные задания конкурируют с пользователями за ресурсы сервера. Тяжёлая обработка, запущенная в разгар рабочего дня, способна «положить» дисковую подсистему и вызвать жалобы всех пользователей. При этом сама по себе система исправна — просто ресурсы заняты.

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

Также стоит проверить, не выполняются ли задания с ошибками в бесконечном цикле перезапуска — такие «зомби» создают постоянную фоновую нагрузку и замусоривают журнал регистрации ошибками.

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

Диагностику стоит вести от наблюдаемого симптома к слою системы. Сначала зафиксируйте, что именно медленно: конкретная операция, всё подряд, работа в определённое время. Затем проверьте загрузку сервера (CPU, память, дисковые очереди) в момент проблемы. Дальше — технологический журнал и анализ долгих запросов.

1. 1
   Зафиксируйте симптом: какая операция, у каких пользователей, в какое время медленная
2. 2
   Проверьте загрузку сервера СУБД и сервера приложений в момент проблемы (диск, память, CPU)
3. 3
   Включите технологический журнал с фильтром по длительным событиям СУБД и блокировкам
4. 4
   Найдите самые долгие запросы и операции, проанализируйте их план выполнения
5. 5
   Устраните найденную причину и повторите замер для проверки эффекта

Контрольные точки

Как проверить результат оптимизации

Время целевой операции до и после изменений

Норма

Сокращение времени в разы при том же объёме данных

Тревожный признак

Время не изменилось или выросло — причина найдена неверно

Дисковые очереди на сервере СУБД

Норма

Очередь близка к нулю в пиковые часы

Тревожный признак

Постоянная очередь запросов к диску — узкое место в подсистеме хранения

Ожидания блокировок

Норма

Единичные кратковременные ожидания

Тревожный признак

Массовые TLOCK-события и взаимоблокировки в журнале

Частые вопросы

Почему 1С тормозит именно в конце месяца или квартала?

В отчётные периоды одновременно растёт число пользователей, объём проводимых документов и количество тяжёлых отчётов. Дополнительно могут запускаться регламентные операции закрытия периода. Система упирается в ресурсы СУБД и блокировки. Помогают разнесение нагрузки по времени, оптимизация отчётов и достаточный запас ресурсов сервера.

Поможет ли увеличение оперативной памяти сервера?

Только если проблема действительно в нехватке памяти: когда рабочий набор данных не помещается в кэш СУБД и идёт постоянное чтение с диска. Если узкое место — медленные диски, плохие запросы или блокировки, добавление памяти эффекта почти не даст. Сначала нужно измерить, куда уходит время.

Файловый или клиент-серверный режим — что быстрее?

Для одного-двух пользователей файловый режим на быстром локальном диске может работать вполне прилично. При росте числа одновременных пользователей клиент-серверный режим выигрывает за счёт управляемых блокировок и кэширования на стороне СУБД. Переход на клиент-сервер — стандартный шаг при росте команды и объёма базы.

Влияет ли антивирус на скорость работы 1С?

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

Как понять, что проблема в запросах конфигурации, а не в железе?

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

Нужно ли регулярно обслуживать базу, если всё работает нормально?

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