Почему очень медленно работает 1С и как это исправить

Медленная работа 1С почти никогда не бывает «просто так» — за ней стоит конкретная причина: перегруженный сервер, неоптимальные запросы к базе данных, огромный журнал регистрации, заблокированные таблицы или устаревшая платформа. Проблема в том, что симптомы у разных причин выглядят одинаково: документы проводятся по 30 секунд, отчёты открываются минутами, а пользователи жалуются на «вылеты».

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

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

Шаг первый: локализуйте проблему

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

Второй важный вопрос — время возникновения. Если система тормозит только утром с 9 до 10, когда все массово заходят и проводят документы, это указывает на нехватку ресурсов под пиковой нагрузкой или на блокировки. Если замедление происходит строго в определённое время, проверьте расписание регламентных заданий, антивирусных проверок и резервного копирования на сервере.

Проверка сервера: память, диски, процессор

Самая частая аппаратная причина — нехватка оперативной памяти на сервере СУБД. SQL Server, PostgreSQL и другие СУБД активно кэшируют данные в память: чем больше база и чем меньше RAM, тем чаще сервер читает данные с диска, а это на порядки медленнее. Откройте диспетчер задач или монитор ресурсов на сервере и посмотрите: если память занята на 95–100% и активно используется файл подкачки, система обречена на тормоза.

Второй критический ресурс — дисковая подсистема. База 1С интенсивно пишет и читает, поэтому размещение базы на медленном HDD вместо SSD даёт заметную просадку, особенно при проведении документов и построении отчётов. Проверьте очередь диска и время отклика в мониторе ресурсов: постоянная очередь и высокое время отклика — признак того, что диск не справляется.

Также убедитесь, что на сервере не работают лишние приложения, съедающие ресурсы: другие базы, файловые службы, виртуальные машины. Частая ситуация — на одном сервере «для экономии» развернули и 1С, и почту, и файловое хранилище, и в итоге страдают все.

Обслуживание базы данных: то, что забывают делать

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

• Обновление статистики — СУБД использует статистику для построения плана запроса; устаревшая статистика приводит к катастрофически неэффективным планам.
• Переиндексация (реорганизация индексов) — фрагментированные индексы замедляют поиск и выборки.
• Очистка процедурного кэша — накопленный кэш неактуальных планов запросов периодически стоит сбрасывать.

Для MS SQL Server эти операции настраиваются через план обслуживания, для PostgreSQL — через autovacuum и ручной VACUUM ANALYZE. Запускайте их в нерабочее время, например ночью, — переиндексация большой базы может занять часы и нагрузить диски.

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

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

Блокировки и одновременная работа пользователей

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

Для диагностики в MS SQL Server используйте представления динамического управления (sys.dm_tran_locks, sys.dm_os_waiting_tasks) или стандартные отчёты по блокировкам. В самой 1С включите технологический журнал с событием TLOCK и TDEADLOCK — он покажет, какие объекты конфликтуют и какие сеансы участвуют.

Типовые меры: перевод управляемых блокировок данных на реквизиты вместо целых таблиц, пересмотр порядка записи объектов в обменах, разнесение тяжёлых операций (закрытие месяца, перепроведение) на нерабочее время. Если взаимоблокировки повторяются на одних и тех же объектах — это повод привлечь разработчика к анализу кода.

Медленные запросы и проблемы конфигурации

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

Инструмент диагностики — встроенный «Замер производительности» (отладка в конфигураторе) и технологический журнал с событиями DBMSSQL/DBPOSTGRS, которые показывают текст запросов и время их выполнения. Запрос, выполняющийся дольше нескольких секунд, — кандидат на анализ плана выполнения в СУБД.

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

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

Сеть, антивирус и рабочие места

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

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

На рабочих местах проверьте версию платформы: смешение разных версий у пользователей иногда приводит к странным задержкам. Также убедитесь, что клиентские компьютеры не работают на пределе памяти — толстый клиент 1С на машине с 4 ГБ RAM, где открыт ещё и браузер с десятком вкладок, будет тормозить независимо от состояния сервера.

Маршрут решения

Как выбрать действие

Память сервера занята на 95%+ и активен swapДобавьте оперативную память или ограничьте потребление других служб

База на HDD и высокая очередь дискаПеренесите базу на SSD

Тормоза только в часы пик у всех пользователейАнализируйте блокировки и разносите тяжёлые операции по времени

Медленно работают конкретные документы или отчётыСнимите замер производительности и анализируйте план запроса

Файловая база и больше 5 одновременных пользователейПланируйте переход на клиент-серверную архитектуру

Тормозит один компьютерПроверьте сеть, антивирус и версию платформы на этом рабочем месте

Проверка результата и типичные ошибки

Любую оптимизацию считайте завершённой только после замера. Зафиксируйте время типовых операций до изменений: проведение конкретного документа, открытие журнала, построение стандартного отчёта. После изменений повторите замеры в сопоставимых условиях. Без цифр «до» и «после» невозможно понять, помогло ли решение, или проблема просто сместилась.

Контрольные точки

Как проверить результат

Время проведения типового документа

Норма

Сократилось в разы или до приемлемых секунд

Тревожный признак

Не изменилось — причина не найдена

Загрузка памяти сервера

Норма

Есть свободный запас, swap почти не используется

Тревожный признак

Память по-прежнему на пределе

Очередь диска в часы пик

Норма

Умеренные значения, быстрый отклик

Тревожный признак

Постоянная высокая очередь

Технологический журнал

Норма

Нет длительных запросов и deadlock

Тревожный признак

Повторяющиеся тяжёлые запросы и взаимоблокировки

Частые вопросы

1С стала тормозить резко, буквально за один день. Что проверить в первую очередь?

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

Поможет ли увеличение оперативной памяти, если база большая?

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

Файловая база тормозит у всех, но переходить на SQL дорого. Что можно сделать?

Оптимизируйте то, что доступно: разместите базу на быстром диске (лучше SSD) выделенного компьютера, обеспечьте стабильную гигабитную сеть, ограничьте число одновременных пользователей, регулярно выполняйте тестирование и исправление со сжатием таблиц, сократите журнал регистрации. Это отсрочит, но не отменит переход на клиент-серверный режим при росте числа пользователей.

Отчёт строится 10 минут, хотя раньше строился за минуту. В чём причина?

Скорее всего, вырос объём данных и устарела статистика, из-за чего СУБД строит неэффективный план запроса. Обновите статистику и перестройте индексы по таблицам, участвующим в отчёте. Если не помогло — снимите замер производительности и проанализируйте запрос отчёта: возможно, нужен дополнительный индекс или доработка схемы компоновки.

Можно ли ускорить 1С настройками самой платформы?

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

Как понять, что пора привлекать специалиста, а не разбираться самостоятельно?

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