Как повысить производительность сервера 1С

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

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

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

Шаг 1. Измерьте, где система теряет время

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

Основные инструменты диагностики: технологический журнал кластера 1С (фиксирует длительные запросы и вызовы), счётчики производительности ОС (загрузка дисков, памяти, процессора), динамические представления СУБД (sys.dm_exec_requests и аналогичные для MS SQL, pg_stat_activity для PostgreSQL) и замеры производительности в конфигураторе.

Обратите внимание на типичные симптомы: если очередь диска постоянно выше 2–3, проблема в подсистеме хранения; если СУБД занимает всю память и начинается свопинг — в нехватке RAM; если время вызовов растёт при увеличении числа пользователей — вероятны блокировки.

Шаг 2. Оптимизируйте дисковую подсистему и память

Диски — самое частое узкое место сервера 1С. База данных, журнал транзакций и временные таблицы (tempdb) генерируют интенсивную случайную нагрузку, с которой классические HDD справляются плохо. Размещение базы на SSD или NVMe-накопителях обычно даёт самый заметный прирост скорости.

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

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

Шаг 3. Настройте СУБД под нагрузку 1С

Настройки СУБД по умолчанию рассчитаны на типовые сценарии и редко оптимальны для 1С. Для MS SQL Server проверьте: максимальный объём памяти сервера, степень параллелизма (max degree of parallelism — для 1С часто рекомендуют ограничивать), размещение tempdb на быстром диске с несколькими файлами, регулярное обновление статистики и обслуживание индексов.

Для PostgreSQL ключевые параметры — shared_buffers (обычно порядка четверти объёма RAM), work_mem, effective_cache_size, настройки автовакуума и параметры записи журнала (wal). Неверные значения work_mem могут привести как к избыточному потреблению памяти, так и к записи временных данных на диск.

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

-- MS SQL: найти самые долгие выполняющиеся запросы
SELECT TOP 20 qs.total_elapsed_time / qs.execution_count AS avg_time_ms,
       qs.execution_count, SUBSTRING(st.text, 1, 200) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY avg_time_ms DESC;

Шаг 4. Настройте кластер серверов 1С

Кластер 1С распределяет нагрузку между рабочими процессами rphost. Если процессов мало, запросы встают в очередь; если слишком много — растёт потребление памяти и накладные расходы на переключение. Ориентируйтесь на число активных пользователей и объём RAM: каждый rphost при интенсивной работе может занимать заметный объём памяти.

Полезные настройки кластера: ограничение объёма памяти на рабочий процесс с перезапуском при превышении (защита от утечек), выключенный по умолчанию отладочный режим на боевом сервере, разнесение сервера 1С и СУБД по разным машинам при высокой нагрузке, чтобы они не конкурировали за ресурсы.

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

Шаг 5. Разведите регламентные задания и пользователей по времени

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

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

Отдельно проверьте, не выполняются ли одновременно операции обслуживания СУБД (реиндексация, бэкап) и регламентные задания 1С — их наложение даёт характерные «провалы» производительности в одно и то же время суток.

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

Шаг 6. Оптимизируйте прикладной уровень

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

Используйте замер производительности в конфигураторе и планы запросов в СУБД, чтобы найти конкретные «тяжёлые» места. Часто ускорение одного отчёта или процедуры проведения документа даёт больший эффект, чем апгрейд сервера, потому что именно эта операция блокирует работу десятков пользователей.

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

Проверка результата и границы самостоятельной работы

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

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

Часто задаваемые вопросы