Администрирование · 12 мин
Что влияет на быстродействие 1С и как ускорить работу системы
Разбираем, что влияет на быстродействие 1С: сервер, СУБД, сеть, настройки конфигурации, регламентные задания и объём базы. Практические шаги диагностики и ускорения.
Медленная работа 1С редко вызвана одной причиной. Обычно это комбинация факторов: слабый дисковый контроллер на сервере СУБД, разросшиеся таблицы итогов, неоптимальный запрос в отчёте и одновременно запущенное регламентное задание обмена данными. Чтобы ускорить систему, нужно сначала понять, где именно теряется время — на клиенте, на сервере 1С, на СУБД или в сети.
Быстродействие 1С определяется пятью основными группами факторов: аппаратные ресурсы серверов, настройки и состояние СУБД, качество кода конфигурации, объём и структура данных, а также инфраструктура — сеть, терминальный доступ, антивирусы. Ниже разберём каждую группу с конкретными признаками проблем и способами их устранения.
Аппаратные ресурсы: процессор, память и диски
Главный аппаратный фактор для серверной 1С — дисковая подсистема сервера СУБД. База данных постоянно читает и пишет страницы данных, журналы транзакций, временные таблицы. Медленные диски (SATA-HDD, перегруженные общие массивы) дают очереди дисковых операций, и вся система «подвисает» даже при мощном процессоре. Для рабочих баз рекомендуются SSD или NVMe, причём журнал транзакций желательно размещать на отдельном быстром накопителе.
Оперативная память влияет на то, сколько данных СУБД может держать в кэше. Если памяти не хватает, сервер вынужден постоянно читать данные с диска — и даже быстрый SSD становится узким местом. Признак нехватки RAM — высокая утилизация диска при умеренной нагрузке на процессор. Для сервера 1С (rphost) память тоже критична: каждый рабочий процесс обслуживает сеансы пользователей и может потреблять гигабайты при тяжёлых операциях.
Процессор важен, но 1С чувствительна не только к количеству ядер, а к частоте ядра: многие операции выполняются однопоточно. Сервер с меньшим числом ядер, но высокой тактовой частотой часто работает быстрее, чем многоядерный «экономичный» CPU с низкой частотой.
Проверить тип накопителей и вынести журнал транзакций на отдельный SSD
Увеличить RAM или ограничить память, выделяемую СУБД, корректно
Искать проблему в запросе, а не докупать ядра
Настроить перезапуск рабочих процессов по объёму памяти
СУБД: настройки и обслуживание базы
В клиент-серверном режиме значительная часть «тормозов» 1С — это проблемы СУБД. Для MS SQL критичны: актуальность статистики, состояние индексов, настройки модели восстановления, размер и фрагментация файлов базы, параметры tempdb. Устаревшая статистика заставляет оптимизатор строить плохие планы запросов — и отчёт, который должен выполняться секунды, работает минутами.
Регулярное обслуживание — обязательный минимум: обновление статистики, реорганизация или перестроение индексов, контроль роста журнала транзакций, очистка процедурного кэша при смене нагрузки. Без регламентного обслуживания база деградирует постепенно, и пользователи привыкают к медленной работе как к норме, пока система не встаёт окончательно.
Для PostgreSQL (в том числе сборок под 1С) важны корректные параметры shared_buffers, work_mem, effective_cache_size и регулярный autovacuum. Настройки «по умолчанию» рассчитаны на слабое оборудование и почти всегда требуют адаптации под реальный сервер.
Конфигурация и качество кода
Даже на мощном сервере плохо написанный код работает медленно. Типичные проблемы: запросы в цикле, обращение к данным через точку («разворачивание» ссылок в запросе), получение всей таблицы вместо выборки нужных полей, отсутствие индексов по полям отборов, неоптимальные виртуальные таблицы без параметров. Один такой отчёт, запущенный пользователем, способен нагрузить сервер на всех.
Особый случай — запросы к виртуальным таблицам регистров (Остатки, Обороты, СрезПоследних) без заданных параметров периода и отборов. Платформа вынуждена строить выборку по всей таблице итогов. Правило простое: всегда передавайте параметры в виртуальную таблицу, а не фильтруйте результат в условии ГДЕ.
Инструменты поиска проблемного кода: технологический журнал (события DBMSSQL, SDBL с длительностью), замеры производительности в конфигураторе, планы запросов на стороне СУБД. Сначала находят самые длительные и самые частые запросы, затем оптимизируют их — эффект от этого обычно больше, чем от апгрейда железа.
// Плохо: фильтрация после виртуальной таблицы
ВЫБРАТЬ Т.Номенклатура, Т.КоличествоОстаток ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки КАК Т ГДЕ Т.Склад = &Склад
// Хорошо: параметры внутри виртуальной таблицы
ВЫБРАТЬ Т.Номенклатура, Т.КоличествоОстаток ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Склад = &Склад) КАК ТОбъём базы и структура данных
С ростом базы замедляются почти все операции: проведение документов, расчёт итогов, отчёты, обмены. База, в которой накоплены миллионы записей по регистрам за много лет, требует больше памяти, дольше обслуживается и медленнее отвечает на запросы. При этом значительная часть старых данных часто не нужна для ежедневной работы.
Основные приёмы работы с объёмом: свёртка базы (перенос остатков на дату и удаление старых документов), установка даты запрета изменения данных, включение итогов только за актуальные периоды, архивация неиспользуемых данных. Дополнительно помогает регулярное удаление помеченных объектов — накопленные «пометки» раздувают таблицы и замедляют выборки.
Отдельный фактор — версионирование объектов и история данных, если они включены. Журналы версий растут быстро и могут занимать заметную долю базы. Включайте версионирование только для действительно важных объектов и настройте срок хранения версий.
Сеть, клиенты и режим работы
В файловом режиме работы база размещается на сетевом ресурсе, и скорость сети напрямую определяет быстродействие: платформа постоянно читает и пишет файл базы по сети. Файловый режим по сети приемлем только для небольшого числа пользователей; с ростом нагрузки переход на клиент-серверный вариант даёт кратный прирост. Размещение файловой базы на Wi-Fi или медленном NAS — типичная причина жалоб.
В клиент-серверном режиме сеть влияет меньше, но важны задержки между сервером 1С и сервером СУБД: их следует размещать в одном сегменте сети, в идеале — на одном оборудовании или с высокоскоростным соединением. Для удалённых пользователей веб-клиент и тонкий клиент через веб-сервер обычно работают быстрее, чем толстый клиент по медленному каналу; альтернатива — терминальный доступ.
На клиентские места влияют антивирусы (проверка файлов базы и каталогов платформы в реальном времени), медленные клиентские ПК с HDD вместо SSD, разряженные шрифты и «тяжёлые» настройки интерфейса. Добавление каталогов 1С в исключения антивируса часто даёт заметный эффект без всяких затрат.
Фоновые процессы и конкуренция за ресурсы
Регламентные и фоновые задания — скрытый потребитель ресурсов. Обмены с сайтом, синхронизация между базами, загрузка курсов, полнотекстовое индексирование, расчёт итогов могут запускаться в разгар рабочего дня и конкурировать с пользователями за процессор и диски. Проверьте расписание: тяжёлые задания должны выполняться ночью, а частота запуска — соответствовать реальной потребности, а не «каждую минуту на всякий случай».
Вторая сторона проблемы — блокировки. При одновременной работе пользователей транзакции блокируют записи и таблицы; если проведение документов спроектировано неудачно (например, контроль остатков по всей таблице), пользователи ждут друг друга. Признаки: система «висит» при одновременном проведении, в технологическом журнале события TLOCK и TDEADLOCK. Решения: управляемый режим блокировок, уменьшение времени транзакций, отказ от избыточных контролей.
Также проверьте, что на сервере СУБД не работают посторонние нагруженные приложения, а виртуальная машина (если сервер виртуализирован) получает гарантированные ресурсы: «раздувание» памяти гипервизором и overcommit процессора заметно снижают производительность 1С.
- 1Зафиксируйте симптом: что именно медленно — вся система, конкретный отчёт, проведение документов, у всех или у одного пользователя
- 2Проверьте загрузку серверов: CPU, память, очередь дисков на сервере СУБД и сервере 1С
- 3Включите технологический журнал с фильтром по длительным событиям СУБД и найдите самые тяжёлые запросы
- 4Проверьте регламентные задания и фоновые процессы в моменты жалоб
- 5Проверьте обслуживание СУБД: дату обновления статистики, фрагментацию индексов
- 6Оптимизируйте найденные запросы и настройки, затем повторите замер и сравните результат
Проверка результата и типичные ошибки
Любую оптимизацию нужно завершать замером: время выполнения конкретной операции до и после изменения. Без замера легко «улучшить» то, что не было проблемой, и пропустить настоящее узкое место. Полезно вести простой журнал: операция, время до, время после, что изменено.
Как проверить результат оптимизации
Сократилось в разы и стабильно при повторных замерах
Изменилось незначительно или улучшение случайное
Нет постоянных очередей, загрузка соответствует активности пользователей
Диск загружен на 100% даже при малом числе пользователей
Длительные события СУБД исчезли или сократились
Те же тяжёлые запросы выполняются так же долго
Копия создана и тестово восстановлена до начала работ
Копии нет или восстановление не проверялось
Частые вопросы
Что даёт больший эффект: апгрейд сервера или оптимизация кода?
Зависит от узкого места. Если тормозит конкретный отчёт или проведение, а сервер при этом недогружен — проблема в запросах и коде, и железо не поможет. Если сервер СУБД упирается в диски и память при обычной работе, апгрейд даст эффект. Поэтому диагностика всегда предшествует покупкам.
Почему 1С тормозит только у одного пользователя?
Значит, проблема локальная: медленный клиентский ПК, антивирус, сетевое подключение этого рабочего места или настройки пользователя (например, открытые при старте тяжёлые отчёты). Сравните работу той же учётной записи на другом компьютере — это быстро отделит проблему клиента от проблемы сервера.
Как понять, что пора переходить с файлового режима на клиент-серверный?
Признаки: база работает по сети, с ней одновременно работают несколько пользователей, растут жалобы на скорость и блокировки, файл базы исчисляется гигабайтами. Клиент-серверный режим переносит нагрузку на СУБД и снимает зависимость от скорости сети между клиентом и файлом базы.
Влияет ли антивирус на скорость 1С?
Да, заметно. Антивирус проверяет файл базы, временные файлы и каталоги платформы при каждом обращении. Добавление каталогов 1С и файлов базы в исключения — стандартная практика; при этом сервер в целом остаётся под защитой. После изменения исключений замерьте скорость типовой операции.
Как часто нужно обслуживать базу на MS SQL?
Минимальный регламент: регулярное обновление статистики и обслуживание индексов (обычно еженедельно или по мере фрагментации), контроль журнала транзакций, резервное копирование ежедневно. Точная периодичность подбирается под интенсивность изменения данных в конкретной базе.
Поможет ли свёртка базы ускорить работу?
Да, если значительная часть объёма — старые документы и движения, не нужные в ежедневной работе. После свёртки уменьшаются таблицы, ускоряются выборки и обслуживание. Но это необратимая операция: выполняйте её на копии, согласуйте с бухгалтерией и проверьте остатки после завершения.
Что важно запомнить
Быстродействие 1С определяется связкой: диски и память сервера СУБД, обслуживание базы, качество запросов в конфигурации, объём данных и фоновые процессы. Начинайте с диагностики через технологический журнал и мониторинг серверов, устраняйте конкретное узкое место и подтверждайте эффект замером. Перед операциями с СУБД и свёрткой всегда делайте проверенную резервную копию.