Администрирование · 11 мин
Как ускорить работу 1С на сервере
Конкретные способы ускорить работу 1С на сервере: настройка СУБД, кластера 1С, железа, индексов и регламентных заданий. Диагностика узких мест и FAQ.
Медленная работа 1С на сервере почти никогда не объясняется «плохой программой» — в подавляющем большинстве случаев причина лежит в одном из четырёх мест: дисковая подсистема сервера СУБД, настройки самой СУБД (MS SQL или PostgreSQL), параметры кластера серверов 1С или состояние самой базы (разросшиеся таблицы, устаревшая статистика, незакрытые периоды). Прежде чем что-то менять, нужно понять, где именно теряется время.
Типичные симптомы различаются по природе проблемы. Если тормозит всё и у всех пользователей — смотрите на сервер: диски, память, настройки СУБД. Если медленно работают отдельные отчёты и документы — вероятнее всего дело в запросах, индексах и объёме данных. Если 1С подтормаживает только в часы пик — проблема в конкуренции за ресурсы: блокировки, регламентные задания в рабочее время, нехватка рабочих процессов.
В этой статье разобран практический порядок действий: от диагностики узкого места до конкретных настроек кластера, СУБД и обслуживания базы. Большинство мер не требуют покупки нового оборудования, но требуют аккуратности: неверные действия на продуктивном сервере могут привести к остановке работы пользователей или потере данных.
Как найти узкое место перед настройкой
Оптимизация без диагностики — главная ошибка. Администраторы часто начинают с покупки дисков или увеличения памяти, хотя реальная причина — один тяжёлый запрос в отчёте или регламентное задание, запущенное в обед. Диагностика занимает от получаса до нескольких часов, но экономит дни бесполезных изменений.
Начните с трёх источников информации. Во-первых, мониторинг ресурсов сервера: загрузка CPU, очередь к диску, свободная оперативная память в моменты жалоб пользователей. Во-вторых, технологический журнал кластера 1С и консоль кластера — там видно длительные вызовы и блокировки. В-третьих, средства самой СУБД: для MS SQL это отчёты по ожиданиям (wait statistics) и активным запросам, для PostgreSQL — pg_stat_statements и pg_stat_activity.
Полезно зафиксировать базовую точку: измерьте время выполнения типовых операций (проведение документа, открытие списка, формирование ключевого отчёта) до начала изменений. Без этих цифр вы не сможете доказать, что оптимизация сработала, и не заметите, если какое-то изменение сделало хуже.
Диски, память, настройки СУБД, загрузка CPU
План запроса, индексы, объём таблиц, статистика
Блокировки, регламентные задания днём, число рабочих процессов
Пинг до сервера, антивирус на сервере, нагрузка на rphost
Настройка кластера серверов 1С
Кластер 1С распределяет нагрузку через рабочие процессы (rphost). Если рабочий процесс один, все пользователи и фоновые задания делят его память и один контекст — при росте нагрузки начинаются очереди. Как правило, для баз с десятками активных пользователей имеет смысл несколько рабочих процессов на сервер, чтобы фоновые задания и сеансы не мешали друг другу.
Проверьте свойства рабочего процесса в консоли кластера: допустимый объём памяти, интервал перезапуска, количество информационных баз на процесс. Перезапуск рабочих процессов по расписанию (например, ночью) помогает при постепенной деградации производительности из-за накопления памяти — это не лечение причины, но рабочая мера стабилизации.
Отдельно настройте требования назначения функциональности. Вынесите фоновые и регламентные задания на отдельный рабочий сервер или отдельный процесс, чтобы ночная обработка данных не конкурировала с интерактивной работой пользователей. Если сервер один — хотя бы ограничьте параллелизм фоновых заданий.
- 1Откройте консоль кластера и посмотрите число рабочих процессов и их загрузку памяти в часы пик
- 2Увеличьте число rphost, если один процесс занят большинством сеансов
- 3Настройте перезапуск рабочих процессов в нерабочее время
- 4Разделите фоновые задания и пользовательские сеансы через требования назначения функциональности
- 5Повторно измерьте время типовых операций и сравните с базовой точкой
Оптимизация СУБД: MS SQL и PostgreSQL
СУБД — самое частое узкое место. Для MS SQL Server проверьте ограничение памяти (max server memory): оно должно быть задано явно, с запасом под операционную систему и сервер 1С, если они на одной машине. Без ограничения SQL Server может занять почти всю память, и система начнёт свопиться — это резко замедляет всё.
Обратите внимание на tempdb: по рекомендациям Microsoft количество файлов tempdb должно соответствовать числу логических процессоров (в разумных пределах), а файлы данных базы 1С и журнал транзакций лучше размещать на разных физических дисках. Параметр max degree of parallelism для 1С часто рекомендуют ограничивать, а также настраивать cost threshold for parallelism — слишком агрессивное распараллеливание запросов 1С иногда вредит.
Для PostgreSQL ключевые параметры — shared_buffers, work_mem, effective_cache_size и настройки автовакуума. Стандартные значения по умолчанию рассчитаны на слабое железо и почти всегда занижены для сервера 1С. Убедитесь, что autovacuum успевает обрабатывать активно изменяемыеся таблицы, иначе база будет разрастаться и деградировать.
Обслуживание базы: индексы, статистика, регламентные задания
База 1С без регулярного обслуживания деградирует предсказуемо: статистика устаревает, оптимизатор строит плохие планы запросов, индексы фрагментируются. Настройте регулярные задания обслуживания: обновление статистики — ежедневно или несколько раз в неделю, перестроение или реорганизация индексов — по расписанию в нерабочее время, очистка процедурного кэша при необходимости.
Проверьте расписание регламентных заданий самой 1С. Частая находка — тяжёлые обмены данными, расчёт итогов, полнотекстовое индексирование или обновление агрегатов, запущенные в середине рабочего дня. Перенесите всё ресурсоёмкое на ночь и разведите задания по времени, чтобы они не стартовали одновременно.
Для больших баз рассмотрите свёртку старых периодов и включение итогов по периодам там, где это поддерживается конфигурацией. Таблицы движений за пять-десять лет замедляют проведение документов и отчёты. Перед свёрткой обязательно сделайте резервную копию и протестируйте процедуру на копии базы — это необратимая операция.
Железо: что действительно влияет на скорость
Если после настройки СУБД и кластера проблема осталась, смотрите на оборудование. Первое по значимости — дисковая подсистема: база 1С должна лежать на SSD, а не на медленных SATA-HDD. Очередь к диску в моменты жалоб — главный индикатор: если она стабильно высокая, диски не справляются.
Второе — оперативная память. Её должно хватать, чтобы СУБД держала в кэше активную часть базы, а операционная система не уходила в своп. Признак нехватки — постоянная высокая дисковая активность при умеренной нагрузке и рост времени отклика по мере работы сервера без перезагрузки.
Третье — процессор и сеть. 1С чувствительна к частоте ядер, поэтому серверные CPU с большим числом медленных ядер не всегда лучше, чем меньшее число быстрых. Сеть между клиентами, сервером 1С и сервером СУБД должна быть стабильной: потери пакетов и высокие задержки дают характерные «подвисания» интерфейса при нормальной загрузке сервера.
Сравнение вариантов
Бесплатно, быстрый эффект, но требует компетенций и осторожности на продуктиве
Даёт стабильный эффект со временем, но не решает проблему слабого железа
Решает аппаратные узкие места, но бесполезен при плохих запросах и настройках
Самый глубокий эффект на конкретных операциях, но требует разработчиков и времени
Типичные ошибки при ускорении 1С
Самая распространённая ошибка — менять всё сразу и ничего не измерять. Вторая по частоте — игнорирование антивируса: файловый антивирус, проверяющий файлы базы данных и каталоги сервера 1С, способен замедлить систему в разы. Добавьте каталоги СУБД и 1С в исключения, но согласуйте это со службой безопасности.
Ещё одна ошибка — размещение сервера 1С и сервера СУБД на одной машине при нехватке памяти: они начинают конкурировать за ресурсы, и оба работают медленнее. Либо разделите их по разным серверам, либо жёстко ограничьте память каждого компонента.
Как проверить, что стало быстрее
После каждого изменения повторяйте замеры тех же операций, что фиксировали в начале: проведение типового документа, открытие журнала, формирование ключевых отчётов. Сравнивайте не ощущения, а секунды. Хорошим подтверждением служит и мониторинг: снижение очереди к диску, уменьшение времени ожиданий в СУБД, сокращение длительных вызовов в технологическом журнале.
Дайте системе поработать несколько дней после изменений: часть эффектов проявляется только под реальной нагрузкой. Если производительность деградирует снова — возвращайтесь к диагностике, вероятно, есть второе узкое место или растёт объём данных.
Как проверить результат
Стабильно ниже исходного замера
Выросло или сильно скачет от попытки к попытке
Низкая, всплески кратковременны
Стабильно высокая при жалобах пользователей
Преобладают лёгкие ожидания, нет длительных блокировок
Доминируют ожидания диска или блокировок
Есть запас, своп не используется
Свободной памяти почти нет, идёт активный свопинг
Что важно запомнить
Ускорение 1С на сервере — это последовательность: диагностика узкого места, настройка кластера и СУБД, регулярное обслуживание базы и только потом апгрейд железа. Каждое изменение делайте по одному, измеряйте результат и всегда имейте актуальную резервную копию перед рискованными операциями.
Частые вопросы
Нужно ли перезагружать сервер 1С регулярно?
Плановая перезагрузка не обязательна, если настроен перезапуск рабочих процессов кластера. Полная перезагрузка сервера оправдана после установки обновлений ОС или при подозрении на системные проблемы, но не должна быть единственным средством борьбы с деградацией производительности.
Поможет ли переход с файловой базы на клиент-серверный вариант?
Да, при числе одновременно работающих пользователей больше нескольких человек клиент-серверный вариант обычно даёт заметный выигрыш за счёт работы СУБД, кэширования и отсутствия конкуренции за файл базы. Однако на маленькой базе и слабом сервере эффект может быть скромным.
Как часто нужно обновлять статистику и перестраивать индексы?
Обновление статистики — ежедневно или несколько раз в неделю в нерабочее время, для активно меняющихся баз — чаще. Перестроение индексов обычно выполняют еженедельно, реорганизацию — чаще. Точная периодичность подбирается по скорости фрагментации конкретной базы.
Что делать, если тормозит только один отчёт?
Это почти всегда проблема конкретного запроса, а не сервера. Снимите план запроса средствами СУБД или используйте консоль запросов с замером, проверьте актуальность статистики по задействованным таблицам и наличие подходящих индексов. Часто помогает переписывание запроса или включение итогов по регистрам.
Влияет ли антивирус на скорость 1С?
Да, файловые антивирусы могут существенно замедлять работу, проверяя файлы базы данных, журналы транзакций и временные файлы сервера 1С. Рекомендуется добавить эти каталоги в исключения проверки, предварительно согласовав исключения со специалистами по информационной безопасности.
Когда стоит привлекать специалиста по оптимизации?
Если после базовых мер — настройки памяти СУБД, обслуживания индексов, разнесения регламентных заданий — проблема сохраняется, а замеры показывают узкое место в коде конфигурации или сложных блокировках, дешевле привлечь специалиста с инструментами анализа технологического журнала, чем продолжать методом проб и ошибок.