Администрирование · 11 мин
Как увеличить масштаб программы 1С и справиться с ростом нагрузки
Практическое руководство по масштабированию 1С: переход с файловой базы на клиент-сервер, оптимизация запросов, кластер серверов и проверка результата.
Когда компания растёт, типовая установка 1С начинает «тормозить»: документы проводятся минутами, отчёты формируются по полчаса, а при одновременной работе десятков пользователей база периодически зависает. Это типичные признаки того, что система упёрлась в пределы текущей архитектуры, и требуется масштабирование — изменение инфраструктуры и настроек под возросшую нагрузку.
Масштабирование 1С — это не одно действие, а последовательность шагов: диагностика узкого места, переход с файлового режима на клиент-серверный, настройка СУБД, оптимизация кода и запросов, при необходимости — кластер серверов и распределение нагрузки. Пропуск диагностики приводит к тому, что деньги тратятся на мощное «железо», а проблема остаётся, потому что причина была в неоптимальном запросе или отсутствии индекса.
Ниже разобран практический порядок действий: как определить, что именно тормозит систему, какие варианты масштабирования существуют, как их внедрять без потери данных и как проверить, что результат достигнут.
Как понять, что система нуждается в масштабировании
Основной признак — деградация скорости работы при росте числа пользователей или объёма данных, хотя раньше всё работало приемлемо. Важно отличать системную проблему от разовой: если отчёт тормозит только у одного сотрудника, дело, скорее, в его компьютере или сети, а не в масштабе системы.
Соберите объективные данные до принятия решений. Замерьте время выполнения типовых операций (проведение документа, формирование отчёта, закрытие месяца) в часы пик и в свободное время. Если разница кратная — нагрузка распределена неравномерно, и проблема именно в конкуренции пользователей за ресурсы.
Файловый режим имеет ограничение на параллельную работу и блокировки всей таблицы
Рост риска повреждения файла и замедление всех операций
Проверить длительные транзакции и блокировки через технологический журнал
Проверить управляемые блокировки и режим разделения данных
Диагностика: найти узкое место до покупки оборудования
Прежде чем что-то менять, включите технологический журнал на сервере 1С и соберите события длительных запросов (DBMSSQL, DBPOSTGRS) и блокировок (TLOCK, TDEADLOCK). Это покажет, какие именно запросы и таблицы создают проблему. Часто выясняется, что 80% времени уходит на 2–3 запроса из отчётов или обменов данными.
Проверьте загрузку оборудования: процессор, память и особенно дисковую подсистему сервера. Для 1С критична скорость дисков (очередь диска, время отклика), а не только их объём. Медленные HDD вместо SSD — одна из самых частых причин «тормозов» даже на мощном сервере.
Используйте Центр управления производительностью (ЦУП) или аналогичные средства мониторинга, если есть возможность. Они показывают картину в динамике: взаимные блокировки, ожидания на СУБД, деградацию по времени суток.
Переход с файловой базы на клиент-серверный режим
Это первый и самый эффективный шаг масштабирования для большинства компаний. В файловом режиме каждый пользователь работает с общим файлом базы напрямую, что вызывает блокировки целых таблиц и ограничивает число одновременных пользователей. Клиент-серверная архитектура переносит обработку данных на СУБД и снимает эти ограничения.
Порядок перехода: разверните СУБД (PostgreSQL с патчами от 1С или MS SQL Server), установите сервер 1С:Предприятия, создайте новую информационную базу в кластере, выгрузите данные из файловой базы в файл .dt и загрузите в новую базу. После загрузки обязательно выполните тестирование и исправление, затем проверьте ключевые операции под нагрузкой.
Выбор СУБД для клиент-серверного режима
Бесплатная, подходит большинству компаний; требует грамотной настройки shared_buffers, work_mem и автовакуума
Платная лицензия, удобные средства администрирования; часто выбирают, если в компании уже есть инфраструктура Microsoft
Для крупных внедрений с особыми требованиями; высокая стоимость и необходимость профильных специалистов
Учтите лицензионную составляющую: для клиент-серверного режима нужна лицензия на сервер 1С, а клиентские лицензии должны покрывать число одновременных сеансов. Это существенная статья расходов, которую закладывают в бюджет заранее.
Настройка СУБД и сервера 1С под нагрузку
Установка СУБД «из коробки» почти никогда не даёт оптимальной производительности. Для PostgreSQL настройте объём разделяемой памяти (shared_buffers), рабочую память для операций (work_mem), параметры автовакуума — без этого база будет деградировать по мере роста. Для MS SQL проверьте модель восстановления базы, настройки tempdb и план обслуживания индексов.
Разместите базу данных, журнал транзакций и временные файлы на быстрых дисках, в идеале — на разных физических устройствах. Сервер 1С и СУБД при высокой нагрузке лучше разносить на разные машины, чтобы процессы не конкурировали за память и процессор.
На сервере 1С настройте кластер: количество рабочих процессов, лимиты памяти на процесс, интервалы перезапуска. Для крупных внедрений используют несколько рабочих серверов в кластере с распределением сеансов и фоновых заданий между ними.
- 1Сделайте полную резервную копию файловой базы и проверьте её восстановление
- 2Разверните СУБД и сервер 1С на тестовом оборудовании
- 3Загрузите копию базы, выполните тестирование и исправление
- 4Настройте параметры СУБД и кластера под ожидаемую нагрузку
- 5Прогоните ключевые операции и замерьте время до и после
- 6Запланируйте переключение пользователей на нерабочее время
- 7После перехода следите за технологическим журналом первые дни
Оптимизация конфигурации и запросов
Даже на мощной инфраструктуре плохой код будет тормозить. Типичные источники проблем: запросы в цикле, получение данных через точку от ссылочных полей («разворачивание» ссылок), отсутствие индексов по полям отбора, чтение лишних данных, неоптимальные виртуальные таблицы без параметров.
Если конфигурация типовая и не изменялась — большая часть оптимизации ложится на настройку СУБД и инфраструктуру. Если есть доработки, проверьте их в первую очередь: самописные отчёты и обработки часто содержат запросы, которые на маленькой базе работали быстро, а на выросшей «умирают».
Полезные приёмы: перенос тяжёлых операций в фоновые задания, включение управляемых блокировок вместо автоматических, использование итогов регистров вместо пересчёта «на лету», архивация старых периодов. Для очень больших баз рассматривают свёртку базы — перенос остатков на дату с удалением старых документов.
Горизонтальное масштабирование: кластер и распределение нагрузки
Когда один сервер перестаёт справляться, применяют горизонтальное масштабирование. В кластере серверов 1С можно добавить несколько рабочих серверов: сеансы пользователей и фоновые задания будут распределяться между ними. Требования к функциональности можно настроить так, чтобы тяжёлые фоновые задания (обмены, расчёты) выполнялись на отдельном сервере и не мешали пользователям.
Для территориально распределённых компаний применяют распределённые информационные базы (РИБ) или обмены через универсальный формат: филиалы работают со своими базами, а данные синхронизируются с центральным узлом. Это снижает требования к каналам связи и разгружает центральную базу.
Отдельное направление — вынос отчётности. Тяжёлые аналитические отчёты можно строить на копии базы (например, на реплике СУБД), чтобы они не конкурировали с оперативной работой пользователей.
Как выбрать направление масштабирования
Проверка результата и контроль после внедрения
Эффективность масштабирования оценивают замерами до и после. Сравните время выполнения контрольных операций в часы пик: проведение документа, формирование типового отчёта, закрытие периода. Результат считается достигнутым, если время сократилось кратно и не деградирует при росте числа пользователей.
После внедрения настройте регулярное обслуживание: обновление статистики и перестроение индексов на СУБД, контроль размера базы и журналов, мониторинг блокировок. Без этого через несколько месяцев производительность снова начнёт падать, и проблему придётся решать заново.
Как проверить результат масштабирования
Секунды, стабильно при разном числе пользователей
Десятки секунд, растёт с увеличением сеансов
Единичные случаи или отсутствуют
Регулярные конфликты блокировок и взаимоблокировки
Процессор и диски имеют запас в пиковые часы
Постоянная загрузка близка к 100%, очередь диска растёт
Длительных запросов и дедлоков мало
Регулярные события TLOCK, TDEADLOCK, долгие запросы
Что важно запомнить
Масштабирование 1С — это последовательность: диагностика узкого места, переход на клиент-серверный режим, настройка СУБД, оптимизация запросов и только затем наращивание оборудования и кластера. Все изменения выполняйте на тестовой копии с резервной копией и планом отката, а результат подтверждайте замерами под нагрузкой.
Частые вопросы о масштабировании 1С
Сколько пользователей выдерживает файловая база 1С?
Точного порога нет — он зависит от интенсивности работы и конфигурации. На практике при 10–15 одновременно работающих пользователях файловый режим обычно начинает давать заметные блокировки и задержки. Если пользователей больше или база активно растёт, переход на клиент-серверный режим оправдан.
Можно ли ускорить 1С без перехода на клиент-сервер?
Частично да: помогает перенос файловой базы на SSD, работа через терминальный сервер вместо сетевого доступа к файлу, оптимизация отчётов и свёртка старых данных. Но это временные меры — ограничения файлового режима по блокировкам они не снимают.
Что лучше для 1С: PostgreSQL или MS SQL Server?
Обе СУБД поддерживаются платформой и при грамотной настройке показывают сопоставимые результаты. PostgreSQL бесплатен, но требует внимательной настройки. MS SQL платный, но удобнее в администрировании для команд, уже работающих с инфраструктурой Microsoft. Выбор обычно определяется бюджетом и компетенциями специалистов.
Нужно ли менять конфигурацию при росте компании?
Не обязательно, но доработки стоит проверить: самописные отчёты и обработки часто содержат неоптимальные запросы, которые проявляются только на больших объёмах. Типовые конфигурации вендор оптимизирует сам, поэтому важно поддерживать их в актуальном состоянии.
Что делать, если база выросла до сотен гигабайт?
Рассмотрите свёртку базы — перенос остатков на выбранную дату с удалением старых документов. Старые данные сохраняют в архивной базе для доступа по требованию. Операцию выполняют только на копии с последующей проверкой остатков по всем разделам учёта.
Сколько времени занимает переход на клиент-серверный режим?
Сроки зависят от размера базы и готовности инфраструктуры: для небольшой базы это дни, для крупной с тестированием и настройкой — недели. Основное время уходит не на саму загрузку данных, а на подготовку, тестирование под нагрузкой и настройку СУБД.