Администрирование · 11 мин
Почему медленно работает 1С и как это исправить
Разбираем, почему медленно работает 1С: слабый сервер, рост базы, неоптимальные запросы, блокировки. Пошаговая диагностика и практические способы ускорения.
Замедление 1С почти никогда не бывает «просто так»: у него всегда есть конкретная техническая причина. Чаще всего виноваты нехватка ресурсов сервера, разросшаяся база данных, неоптимальные запросы в конфигурации, блокировки при одновременной работе пользователей или проблемы сети в файловом режиме. Пока причина не найдена, любые «ускорения» — это действия вслепую.
Диагностику стоит начинать с простого вопроса: тормозит у всех пользователей или у одного, всегда или в определённые часы, вся программа или конкретные операции — проведение документов, формирование отчётов, открытие списков. Ответы на эти вопросы сразу сужают круг поиска в несколько раз.
Ниже разобраны основные причины медленной работы 1С и практические шаги по устранению каждой из них. Материал ориентирован на администраторов и внедренцев, но большая часть проверок доступна и опытному пользователю с правами администратора базы.
Первый шаг: определить, где именно теряется время
Прежде чем что-то менять, зафиксируйте симптомы измеримо. Встроенный инструмент «Замер производительности» (в режиме «1С:Предприятие» через меню «Все функции — Стандартные — Замер производительности» или через конфигуратор) показывает, какие строки кода и запросы занимают больше всего времени при выполнении конкретной операции.
Параллельно проверьте загрузку сервера: процессор, оперативную память, дисковую подсистему. Если при «зависании» 1С диски загружены на 100% или память исчерпана, проблема аппаратная или в настройках СУБД, а не в конфигурации. Для клиент-серверного варианта полезен технологический журнал платформы — он фиксирует длительные вызовы, запросы и блокировки.
Важно различать режимы: в файловом варианте база лежит в общей сетевой папке, и скорость работы напрямую зависит от сети и диска того компьютера, где лежит файл. В клиент-серверном варианте основная нагрузка ложится на сервер СУБД (MS SQL, PostgreSQL), и диагностика ведётся уже там.
Как проверить результат
Основное время уходит на 1–2 ожидаемо тяжёлых запроса
Время размазано по сотням мелких вызовов или один запрос занимает десятки секунд
Активность диска умеренная, очередь небольшая
Диск загружен на 100%, растёт очередь запросов
Свободная память есть, подкачка не используется активно
Память исчерпана, идёт активная работа с файлом подкачки
Причина 1: слабое оборудование и неправильные настройки сервера
Самая частая аппаратная причина — медленные диски. База 1С интенсивно читает и пишет данные, поэтому размещение базы на обычных HDD вместо SSD даёт заметные задержки, особенно при одновременной работе нескольких пользователей. Второй фактор — нехватка оперативной памяти: СУБД не может держать в кэше активно используемые данные и постоянно обращается к диску.
Для MS SQL важно ограничить максимальный объём памяти сервера (параметр max server memory), чтобы СУБД не отбирала всю память у операционной системы. Также проверьте схему электропитания сервера: режим «Экономия энергии» заметно снижает производительность процессора — должен стоять «Высокая производительность».
Антивирус на сервере — отдельный источник тормозов. Файлы базы данных и каталоги СУБД должны быть добавлены в исключения проверки в реальном времени, иначе каждая операция чтения-записи проходит дополнительное сканирование.
Причина 2: разросшаяся база и устаревшая статистика
С годами база накапливает документы, движения регистров, версии объектов, историю обменов. Большие таблицы медленнее сканируются, индексы разрастаются и фрагментируются, планы запросов ухудшаются. Характерный признак — постепенное, плавное замедление за месяцы и годы без изменений в конфигурации.
Регулярное обслуживание СУБД включает обновление статистики, перестроение или реорганизацию индексов и очистку устаревших данных. В MS SQL это делается планом обслуживания (maintenance plan), в PostgreSQL — регламентными операциями vacuum и analyze. Без этого СУБД строит запросы на основе устаревших представлений о данных и выбирает неэффективные планы.
Отдельно проверьте журнал регистрации и хранение версий объектов: при включённом версионировании без ограничения срока хранения таблицы версий могут стать одними из самых больших в базе. Ограничьте глубину хранения разумным сроком.
- 1Сделайте полную резервную копию базы и проверьте её восстановление на тестовом стенде
- 2Обновите статистику по всем таблицам базы средствами СУБД
- 3Выполните реорганизацию или перестроение фрагментированных индексов
- 4Очистите устаревшие данные: старые версии объектов, лишние записи журнала регистрации, остатки незавершённых обменов
- 5Настройте автоматическое выполнение этих операций по расписанию в нерабочее время
Причина 3: блокировки при одновременной работе пользователей
Если 1С «подвисает» именно в часы пиковой активности, а вечером летает — вероятны блокировки. Когда один пользователь проводит крупный документ или запускает тяжёлый отчёт, он устанавливает блокировки на таблицы, и остальные ждут их снятия. Внешне это выглядит как зависание программы у всех сразу.
Диагностируются блокировки через технологический журнал (события TLOCK, TDEADLOCK) и средства мониторинга СУБД. Взаимоблокировки (deadlock) платформа завершает принудительно с ошибкой, а простые ожидания просто съедают время пользователей.
Типовые меры: перевод базы в режим управляемых блокировок (для старых конфигураций), разнесение тяжёлых операций (закрытие месяца, массовые перепроведения, большие отчёты) на нерабочие часы, ограничение прав на запуск ресурсоёмких обработок в рабочее время.
Простой тест на блокировки: попросите пользователей зафиксировать точное время «зависания» и сопоставьте его с тем, что в этот момент делали другие сотрудники. Часто выясняется, что тормоза совпадают с запуском конкретного отчёта или обмена данными.
Причина 4: неоптимальный код и запросы в конфигурации
Если тормозит конкретная операция независимо от времени суток и числа пользователей, причина почти всегда в коде. Классические ошибки разработчиков: запросы в цикле, получение данных через точку от ссылки («разворачивание» ссылок), отсутствие индексов по полям отборов, выборка лишних полей и строк, обход огромных таблиц без фильтрации.
Замер производительности покажет проблемные строки. Для запросов полезен план запроса в СУБД: если видите сканирование всей таблицы там, где должен быть поиск по индексу, — запрос или структура метаданных требуют доработки. Нестандартные индексы можно добавить в конфигураторе без снятия конфигурации с поддержки в ряде случаев, но любые доработки сначала проверяются на копии базы.
Отчёты на СКД часто тормозят из-за соединений с виртуальными таблицами без отборов по периоду. Проверьте, что в отчёте обязательно задаётся период и что отборы передаются в параметры виртуальных таблиц, а не накладываются на результат.
Причина 5: файловый режим и медленная сеть
Файловый вариант работы подходит для небольших баз и нескольких пользователей. При росте базы и числа одновременных пользователей он неизбежно становится узким местом: весь трафик данных идёт по сети, а сетевые папки на Windows не рассчитаны на интенсивную многопользовательскую работу с большим файлом.
Признаки проблемы: база быстро открывается локально на компьютере, где лежит файл, но медленно у всех остальных; скорость сильно зависит от загрузки сети; копирование файла базы по сети идёт медленно. Проверьте скорость сети простым копированием большого файла — если она низкая, сначала разбирайтесь с сетевым оборудованием.
Кардинальное решение — переход на клиент-серверный вариант (MS SQL или PostgreSQL) либо публикация базы на веб-сервере с работой через тонкий клиент. Оба варианта убирают зависимость от протокола сетевых папок, но требуют администрирования СУБД или веб-сервера.
Файловый и клиент-серверный режимы
Подходит для 1–5 пользователей и небольшой базы. Прост в развёртывании, но чувствителен к сети и не масштабируется.
Для десятков пользователей и больших баз. Требует сервера, СУБД и регулярного обслуживания, но снимает ограничения файлового режима.
Промежуточный вариант: снижает требования к сети и клиентским машинам, подходит для удалённых подразделений.
Что делать, если ничего не помогло
Если обслуживание выполнено, ресурсов хватает, а тормоза остаются — соберите технологический журнал за период «зависаний» и проанализируйте длительные события. Часто обнаруживаются неочевидные причины: фоновые задания, обмены с другими системами, регламентные операции, запущенные в неподходящее время, или доработки сторонних подрядчиков.
Проверьте список активных фоновых и регламентных заданий: иногда «залипшее» задание годами гоняет тяжёлую обработку каждые несколько минут. Также посмотрите настройки функциональных опций — включённые, но неиспользуемые механизмы добавляют лишние проверки и запросы в каждую операцию.
Когда собственных компетенций не хватает, задача переходит к специалисту по оптимизации 1С или вендору СУБД. Передавайте ему не жалобы, а данные: замеры производительности, выгрузку технологического журнала, конфигурацию сервера — это сократит время диагностики в разы.
Что важно запомнить
Не ускоряйте вслепую: сначала замерьте, где теряется время. Основные причины тормозов 1С — диски и память сервера, отсутствие регламентного обслуживания СУБД, блокировки, неоптимальные запросы и файловый режим при большой нагрузке. Любые операции с базой — только после резервной копии.
Частые вопросы
1С тормозит только у одного пользователя, у остальных всё быстро. В чём причина?
Проблема почти наверняка на стороне клиента: слабый компьютер, антивирус, сканирующий процессы 1С, медленное сетевое подключение (особенно Wi-Fi вместо кабеля) или устаревшая версия платформы на этом ПК. Проверьте скорость на другом компьютере под тем же пользователем — так вы отделите проблему машины от проблемы учётной записи.
База работала нормально, а после обновления конфигурации стала медленной. Что делать?
Сначала дождитесь завершения отложенных обработчиков обновления — после обновления они могут часами обрабатывать данные в фоне и грузить сервер. Если обновление завершено, а тормоза остались, сделайте замер производительности на проблемной операции и сравните с поведением до обновления: вероятно, в новой версии появился неоптимальный запрос или изменилась логика проведения.
Поможет ли ускорению переход на SSD?
Если база сейчас размещена на HDD — да, переход на SSD обычно даёт заметное ускорение, особенно при одновременной работе пользователей, потому что база интенсивно выполняет случайные операции чтения-записи. Но если узкое место — неоптимальный запрос или блокировки, быстрый диск лишь немного сгладит симптомы.
Как часто нужно обновлять статистику и перестраивать индексы?
Универсальной нормы нет: частота зависит от интенсивности изменения данных. Для активно пополняемых баз обновление статистики обычно выполняют ежедневно или несколько раз в неделю, реорганизацию индексов — еженедельно, полное перестроение — реже и по показаниям фрагментации. Ориентируйтесь на мониторинг, а не на фиксированный календарь.
Можно ли ускорить 1С, отключив журнал регистрации?
Отключение журнала регистрации даст лишь незначительный эффект и при этом лишит вас важного инструмента аудита и расследования инцидентов. Разумнее ограничить уровень детализации журнала и периодически сокращать его объём, сохраняя историю за разумный срок.
Отчёт формируется несколько минут — это нормально?
Зависит от объёма данных и построения отчёта. Если отчёт обращается к виртуальным таблицам без отбора по периоду или соединяет большие таблицы, минуты ожидания — признак неоптимальности, а не норма. Проверьте отчёт замером производительности: обязательные параметры периода и корректные отборы обычно сокращают время формирования в разы.