1С сильно тормозит: что делать и как найти причину

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

Подход к решению зависит от режима работы. В файловой базе на одном компьютере чаще всего виноваты диск, антивирус и сеть (если база лежит на общей папке). В клиент-серверном варианте добавляются настройки SQL Server или PostgreSQL, параметры кластера 1С и блокировки между пользователями. Диагностика в этих сценариях отличается, и смешивать методы не стоит.

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

Шаг 1. Определите, где именно тормозит система

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

Откройте диспетчер задач Windows на проблемном компьютере и на сервере (если он есть) в момент «зависания». Смотрите загрузку процессора, памяти и диска. Диск, загруженный на 100% при простое, — почти всегда признак проблемы: антивирусное сканирование, фрагментированная файловая база, медленный HDD вместо SSD или нехватка оперативной памяти, из-за которой система активно использует файл подкачки.

Полезный тест: попросите пользователя повторить операцию на другом компьютере или под другим сеансом. Если на другом рабочем месте всё быстро — проблема локальная (слабый ПК, антивирус, сетевой кабель). Если медленно везде — ищите причину на сервере или в самой базе.

Шаг 2. Проверьте оборудование и базовую инфраструктуру

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

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

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

Шаг 3. Устраните типовые программные причины

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

В файловом режиме помогает сжатие таблиц информационной базы (через конфигуратор: Администрирование → Тестирование и исправление, либо параметр сжатия при выгрузке/загрузке через dt). Со временем файл 1Cv8.1CD разрастается за счёт удалённых, но физически не вычищенных данных. Выгрузка базы в dt и загрузка обратно физически пересоздаёт файл и нередко уменьшает его в разы. Операция требует монопольного доступа и времени, пропорционального размеру базы.

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

1. 1
   Завершите все сеансы пользователей и сделайте резервную копию (выгрузку в dt)
2. 2
   Добавьте каталог базы в исключения антивируса на всех компьютерах
3. 3
   Перенесите базу с сетевой папки на локальный SSD или поднимите сервер 1С
4. 4
   Выполните тестирование и исправление со сжатием таблиц в конфигураторе
5. 5
   Проверьте скорость типовых операций и сравните с исходными замерами

Шаг 4. Настройте СУБД в клиент-серверном варианте

Если 1С работает на MS SQL Server или PostgreSQL, значительная часть тормозов живёт именно там. Типовые проблемы MS SQL: модель восстановления Full без обслуживания журнала транзакций (журнал разрастается и тормозит всё), отсутствие регламентного обновления статистики и перестроения индексов, автоприращение файлов данных маленькими порциями, размещение данных и журнала на одном медленном диске.

Настройте регламентное обслуживание: регулярное обновление статистики, перестроение или реорганизацию индексов, контроль размера журнала транзакций, резервное копирование средствами СУБД. Эти операции планируйте на нерабочее время — перестроение индексов на больших таблицах нагружает диск и может само стать причиной «тормозов по ночам».

В кластере 1С проверьте настройки рабочих процессов и ограничения памяти. Слишком мало рабочих процессов — запросы пользователей стоят в очереди; слишком много — процессы конкурируют за память и процессор. Также убедитесь, что сервер 1С и сервер СУБД связаны быстрой сетью, а в идеале размещены на одном оборудовании или в одном сегменте сети.

Шаг 5. Найдите тяжёлые операции и блокировки

Когда инфраструктура в порядке, а тормоза остаются, причина обычно в конкретных запросах и блокировках. Включите технологический журнал на сервере 1С с отбором по длительным событиям (DBMSSQL, DBPOSTGRS, EXCP, TLOCK) — он покажет, какие запросы выполняются долго и кто кого блокирует. Для разбора журнала удобно использовать стандартные инструменты анализа ТЖ или консольные скрипты.

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

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

Перед любыми оптимизациями замерьте время 3–5 типовых операций (открытие документа, проведение, отчёт) и запишите. Без «до» и «после» невозможно понять, помогло ли изменение, а при откате — вернуться к исходной точке.

Шаг 6. Проверьте конфигурацию и данные

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

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

Шаг 7. Когда самостоятельных мер недостаточно

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

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

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

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

Файловая база, 2–5 пользователей, сетевая папкаПеренесите базу на локальный SSD или поднимите сервер 1С с веб-доступом

Клиент-сервер, тормоза у всех, диск сервера на 100%Проверьте журнал транзакций, индексы, статистику и скорость дисков СУБД

Тормозит один конкретный отчёт или операцияСнимите замер в технологическом журнале и ищите тяжёлый запрос

Тормоза строго в одно и то же времяПроверьте регламентные задания, антивирусные проверки и расписание бэкапов

Тормозит только у одного пользователяПроверьте его ПК: антивирус, диск, память, сетевое подключение

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

1С тормозит только утром, когда все заходят. Что делать?

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

Поможет ли увеличение оперативной памяти на сервере?

Поможет, только если память действительно является узким местом — это видно по постоянной загрузке под 100% и активному использованию файла подкачки. Если узкое место — диск или неоптимальные запросы, добавление памяти эффекта почти не даст.

Можно ли ускорить файловую базу без перехода на SQL?

Да: перенос на SSD, исключения антивируса, сжатие базы через тестирование и исправление, отказ от сетевой папки в пользу веб-сервера 1С. Но при росте числа пользователей файловый режим всё равно упирается в свои ограничения.

Опасно ли запускать «Тестирование и исправление»?

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

После обновления конфигурации 1С стала работать медленнее. Почему?

Частые причины: первое обновление статистики и пересчёт итогов после обновления, новые регламентные задания, изменённые запросы в новом релизе. Дайте системе пройти регламентное обслуживание, проверьте фоновые задания; если не помогло — снимайте замер и сравнивайте с поведением на прошлом релизе.

Как понять, что пора переходить с файлового режима на клиент-серверный?

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