Администрирование · 12 мин
Почему тормозит 1С и как ускорить её работу
Разбираем основные причины медленной работы 1С: сервер, сеть, СУБД, конфигурация и регламентные задания. Практические шаги диагностики и ускорения работы программы.
Медленная работа 1С почти никогда не имеет одной-единственной причины. Долгие открытия документов, «подвисания» при проведении, вечное формирование отчётов — всё это симптомы, за которыми стоят проблемы сервера, сети, СУБД, конфигурации или настроек самой платформы. Чтобы ускорить систему, нужно сначала локализовать узкое место, а уже потом что-то менять.
Первый практический шаг — определить, тормозит 1С у всех пользователей или только у части. Если медленно у всех и в любое время, подозрение падает на сервер, СУБД и конфигурацию. Если страдают отдельные сотрудники — проверяйте их компьютеры, сетевое подключение и антивирус. Если проблемы возникают только в определённые часы, вероятный виновник — регламентные задания, обмены данными или пиковая нагрузка.
Второй важный вопрос — режим работы базы. Файловая база на общем сетевом диске и клиент-серверный вариант на SQL тормозят по совершенно разным причинам, и методы лечения различаются. Ниже разберём основные источники проблем и конкретные действия для каждого случая.
Серверное оборудование: диски, память и процессор
Самый частый аппаратный виновник — медленные диски. База 1С интенсивно читает и пишет данные, и если СУБД размещена на обычных SATA-HDD, узким местом становится именно дисковая подсистема. Перенос базы и журналов транзакций на SSD часто даёт самый заметный прирост скорости без изменения кода и настроек.
Оперативной памяти должно хватать и серверу 1С, и серверу СУБД. Если MS SQL Server или PostgreSQL ограничен в памяти, он не может кэшировать данные и постоянно обращается к диску. Проверьте, какой объём памяти выделен СУБД, и нет ли на сервере конкуренции за ресурсы с другими приложениями.
Процессор влияет на скорость выполнения запросов и работу регламентных заданий. Для 1С важна не только суммарная мощность, но и производительность одного ядра: многие операции выполняются последовательно. Виртуализация тоже может «съедать» ресурсы — проверьте, не перегружен ли гипервизор и не урезаны ли лимиты для виртуальной машины.
Смотрите загрузку дисков, памяти, блокировки в СУБД
Проверьте их ПК, антивирус, качество сетевого подключения
Откройте консоль заданий и журнал регистрации на это время
Замерьте запросы в консоли, проверьте планы выполнения
Настройки и обслуживание СУБД
Даже мощный сервер не спасёт, если СУБД настроена неправильно или не обслуживается. Со временем фрагментируются индексы, устаревает статистика, и оптимизатор запросов начинает выбирать неэффективные планы выполнения. Внешне это выглядит так: база «постепенно деградировала», хотя никто ничего не менял.
Минимальный регламент обслуживания для MS SQL Server включает регулярное обновление статистики, перестроение или реорганизацию индексов и контроль размера журнала транзакций. Для PostgreSQL аналогичные задачи решают autovacuum и периодический анализ таблиц. Если этих процедур нет в расписании — добавьте их, это одна из самых дешёвых мер по ускорению.
Отдельно проверьте настройки самой СУБД: лимит памяти, размещение tempdb (для MS SQL её рекомендуют держать на быстром диске), модель восстановления базы. Полная модель восстановления без регулярного бэкапа журнала приводит к его разрастанию до десятков гигабайт, что замедляет операции записи.
Блокировки и конкурентная работа пользователей
Если 1С «подвисает» при проведении документов, особенно когда несколько человек работают с одними данными, вероятна проблема блокировок. Один сеанс удерживает блокировку на таблицу или диапазон записей, остальные ждут в очереди. Пользователь видит вращающийся курсор, хотя сервер при этом почти не нагружен.
Диагностировать блокировки можно через консоль кластера серверов 1С (список сеансов и соединений) и средствами СУБД — например, динамическими представлениями sys.dm_tran_locks в MS SQL. В журнале регистрации 1С фиксируются события взаимоблокировок и таймаутов, если включён соответствующий уровень протоколирования.
Типичные источники блокировок: проведение документов в монопольной логике, списание остатков по одним и тем же складам и номенклатуре, обмены данными, выполняющиеся в рабочее время, и код, который удерживает транзакцию слишком долго. Часть проблем решается переводом регистров на управляемые блокировки (режим «Управляемый» в свойствах конфигурации) и корректировкой кода.
Конфигурация и качество кода
Не все тормоза лечатся железом. Тяжёлые запросы без нужных индексов, обход больших таблиц в цикле, запросы внутри циклов, неоптимальные отчёты на СКД — всё это способно затормозить даже мощный сервер. Характерный признак: конкретная операция (отчёт, обработка, проведение определённого документа) выполняется непропорционально долго.
Для поиска проблемных мест используйте замеры производительности. В конфигураторе доступен режим замера, а на сервере — технологический журнал с фильтрами по длительности событий. Запросы, выполняющиеся дольше нескольких секунд, стоит разобрать в консоли запросов и посмотреть план выполнения на стороне СУБД.
Отдельный случай — разросшиеся таблицы. Итоги регистров, таблицы изменений для обменов, журналы регистрации и служебные таблицы версионирования со временем раздуваются. Очистка устаревших данных, настройка сроков хранения версий объектов и свёртка старых периодов заметно разгружают базу.
- 1Определите масштаб: тормозит у всех, у части пользователей или только одна операция
- 2Проверьте загрузку сервера: диски, память, CPU в момент тормозов
- 3Посмотрите блокировки: консоль кластера, журнал регистрации, средства СУБД
- 4Проверьте регламентные задания и обмены на время возникновения проблем
- 5Включите технологический журнал и найдите самые длительные запросы
- 6Выполните обслуживание СУБД: статистика, индексы, журнал транзакций
- 7Повторите замер после каждого изменения, чтобы понять эффект
Сеть, клиентские компьютеры и антивирус
Для файловых баз, размещённых на сетевом диске, сеть — критический фактор. Медленный канал, Wi-Fi вместо проводного подключения, перегруженный коммутатор или антивирус, сканирующий каждый файл базы при обращении, делают работу мучительной. Файловый режим вообще плохо масштабируется: при росте числа пользователей и объёма данных стоит планировать переход на клиент-серверный вариант.
На клиентских компьютерах проверьте: не сканирует ли антивирус каталоги 1С и СУБД (их нужно добавить в исключения), хватает ли памяти, не запущены ли ресурсоёмкие фоновые программы. Тонкий клиент и веб-клиент менее требовательны к машине пользователя, чем толстый клиент — это один из способов снизить нагрузку на старые ПК.
Для удалённых филиалов и сотрудников рассмотрите работу через веб-сервер или RDP на терминальном сервере рядом с базой вместо прямого подключения через медленный канал. Передача экрана по RDP требует заметно меньше трафика, чем обмен данными между клиентом и сервером 1С.
Файловый или клиент-серверный режим
Подходит для небольших команд и малых объёмов данных. Ограничения: чувствительна к качеству сети, слабо переносит конкурентную работу, сложнее обслуживать при росте.
Подходит при росте числа пользователей и объёма данных. Требует администрирования СУБД и сервера 1С, но даёт управляемые блокировки, фоновые задания и нормальное обслуживание индексов.
Подходит для удалённых пользователей и слабых каналов. Ограничение: нужна дополнительная инфраструктура и её поддержка.
Регламентные задания и обмены данными
Фоновые процессы — частая скрытая причина «дневных тормозов». Обмены с сайтом, синхронизация между базами, загрузка курсов и прайсов, пересчёт итогов могут запускаться прямо в разгар рабочего дня и отбирать ресурсы у пользователей. Откройте консоль регламентных и фоновых заданий и сопоставьте расписание с жалобами на производительность.
Тяжёлые задания переносите на ночь или на периоды минимальной нагрузки. Если задание должно выполняться часто, оптимизируйте его: обрабатывайте данные порциями, ограничивайте объём выборки, избегайте длительных транзакций. Долгие обмены в одной транзакции — классический источник массовых блокировок.
Полезно назначить для фоновых заданий отдельный рабочий сервер кластера или ограничить их количество, чтобы они не вытесняли интерактивные сеансы пользователей. В консоли кластера это настраивается через требования назначения функциональности.
Контроль результата и когда привлекать специалиста
Любое изменение — перенос на SSD, перестроение индексов, правка запроса — оценивайте замером «до и после». Зафиксируйте время выполнения типовых операций: открытие списка документов, проведение реализации, формирование ключевого отчёта. Без таких контрольных точек невозможно понять, что реально помогло.
Самостоятельно безопасно выполнять: настройку исключений антивируса, перенос регламентных заданий по расписанию, обновление статистики и перестроение индексов (при наличии резервной копии), очистку устаревших данных штатными средствами. Изменение кода конфигурации, настройку кластера серверов и тонкую оптимизацию СУБД лучше доверить специалисту с опытом администрирования 1С.
Как проверить результат
Открытие занимает секунды, без видимых зависаний
Ожидание десятки секунд, курсор-ожидание
Нет массовых таймаутов и взаимоблокировок
Регулярные ошибки блокировок в рабочее время
Диски не уходят в 100% очередь надолго
Постоянная очередь к диску и 100% активность
Тяжёлые задания выполняются ночью и завершаются успешно
Задания накладываются на рабочие часы или падают с ошибками
Что важно запомнить
Тормоза 1С — это симптом, а не диагноз. Сначала локализуйте узкое место (клиент, сеть, сервер, СУБД, код), затем устраняйте его и проверяйте результат замером. Чаще всего помогают быстрые диски, обслуживание индексов и статистики, борьба с блокировками и перенос тяжёлых регламентных заданий на нерабочее время.
Частые вопросы
Почему 1С стала тормозить постепенно, хотя никто ничего не менял?
Это классическая картина деградации СУБД: фрагментировались индексы, устарела статистика, выросли таблицы и журнал транзакций. Начните с регламентного обслуживания базы — обновления статистики и перестроения индексов, предварительно сделав резервную копию.
Поможет ли переход на SSD, если тормозит файловая база по сети?
Только частично. Если база лежит на сетевом диске, узким местом часто является сама сеть и протокол доступа к файлам, а не диск сервера. SSD на машине, где размещён файл базы, поможет, но при росте числа пользователей правильнее рассмотреть переход на клиент-серверный вариант.
Как понять, что виноват антивирус?
Добавьте каталоги базы, СУБД и исполняемых файлов 1С в исключения антивируса и сравните скорость типовых операций до и после. Если разница заметна — оставьте исключения постоянно. Полностью отключать антивирус ради теста не обязательно и небезопасно.
Отчёт формируется по несколько минут — это нормально?
Для больших объёмов данных длительное формирование возможно, но часто причина в неоптимальном запросе или отсутствии подходящих индексов. Снимите замер запроса через консоль запросов и посмотрите план выполнения в СУБД: полное сканирование больших таблиц — признак того, что запрос можно ускорить.
Что делать, если тормоза возникают только при одновременной работе нескольких пользователей?
Это типичный признак блокировок. Проверьте журнал регистрации на предмет таймаутов и взаимоблокировок, посмотрите активные соединения в консоли кластера. Решение обычно лежит в области управляемых блокировок, сокращения длительности транзакций и переноса обменов на нерабочее время.
Когда стоит привлекать специалиста, а не разбираться самостоятельно?
Если обслуживание СУБД и настройка расписания заданий не помогли, а проблема уходит в код конфигурации, архитектуру обменов или тонкую настройку кластера — разумнее привлечь специалиста по производительности 1С. Ошибочные изменения в этих областях могут привести к потере данных или остановке работы всей компании.