Администрирование · 13 мин
1С тормозит: что делать и как найти причину
1С тормозит: разбираем причины медленной работы — сервер, СУБД, сеть, регламентные задания, блокировки. Пошаговая диагностика и конкретные действия по ускорению.
Медленная работа 1С почти никогда не имеет одной причины: обычно это сочетание перегруженного сервера, неоптимальных запросов к базе, блокировок между пользователями и устаревших настроек СУБД. Поэтому первый шаг — не «починить», а локализовать проблему: тормозит вся система у всех пользователей, только одна операция (проведение документа, формирование отчёта) или только у конкретных рабочих мест.
Простой тест: попросите двух пользователей одновременно выполнить одну и ту же операцию. Если у обоих медленно — проблема на сервере или в базе данных. Если медленно только у одного — смотрите его компьютер, сеть или клиентские настройки. Если тормозит только конкретный документ или отчёт — вероятнее всего, проблема в запросах, избыточных данных или блокировках.
Дальнейшие действия зависят от режима работы: файловая база на общем диске, клиент-серверный вариант с MS SQL Server, PostgreSQL или другой СУБД. Подходы к диагностике заметно различаются, и ниже они разобраны отдельно.
Шаг 1. Определите масштаб проблемы
Зафиксируйте факты до начала любых изменений. Запишите: сколько пользователей работает одновременно, какие операции выполняются медленно, в какое время суток проблема усиливается, когда она появилась впервые и что менялось перед этим (обновление конфигурации, переезд на новый сервер, рост объёма данных).
Замедление по расписанию — например, каждый день в 10:00 или в момент закрытия смены — почти всегда указывает на регламентные задания, обмены данными или резервное копирование, запущенные в рабочее время. Резкое ухудшение после обновления указывает на изменения в коде конфигурации или на необходимость обновить статистику в СУБД.
Загрузку CPU, RAM, дисков на сервере; активные блокировки
Его сеть, антивирус, версию платформы, режим работы клиента
Замер производительности, размер таблиц, индексы
Регламентные задания, обмены, бэкапы в это время
Шаг 2. Проверьте сервер и ресурсы
Откройте монитор ресурсов на сервере в момент, когда пользователи жалуются на тормоза. Ключевые показатели: загрузка процессора (устойчивые 90–100% — нехватка CPU), свободная оперативная память (если её почти нет, система уходит в файл подкачки и всё резко замедляется) и очередь диска (значения выше 2–3 указывают на то, что дисковая подсистема не справляется).
Для базы данных критичны именно диски: размещение базы на медленных HDD или на том же диске, где лежит операционная система и файл подкачки, — частая причина тормозов. Также проверьте, что сервер не работает в режиме экономии энергии: схема электропитания «Высокая производительность» в Windows даёт заметный прирост для СУБД.
Отдельно проверьте антивирус на сервере. Каталоги базы данных, временные файлы платформы и файлы журнала транзакций должны быть добавлены в исключения проверки в реальном времени — иначе каждая операция записи проходит через антивирусный фильтр.
Шаг 3. Проверьте регламентные задания и обмены
В консоли заданий (доступна через типовую обработку «Консоль заданий» или встроенные средства конфигурации) посмотрите, какие регламентные и фоновые задания выполняются, как часто и сколько длятся. Типичные виновники: полная синхронизация с сайтом каждые 5 минут, обмен с другими базами, пересчёт итогов, загрузка курсов валют, рассылка отчётов.
Что можно сделать безопасно: перенести тяжёлые задания на ночное время, увеличить интервал между запусками, отключить задания, которые не используются. Задания, выполняющиеся с ошибками в цикле, тоже нагружают систему — их нужно либо исправить, либо отключить до разбирательства.
Если задание зависло и держит блокировку, завершите его через консоль заданий, а не перезапуском сервера. После этого проверьте журнал регистрации: там видно, на каком объекте задание конфликтовало с пользователями.
- 1Откройте консоль заданий и отсортируйте по длительности выполнения
- 2Найдите задания, работающие дольше нескольких минут в рабочее время
- 3Перенесите их на нерабочие часы или увеличьте интервал запуска
- 4Отключите неиспользуемые и циклически падающие задания
- 5Проверьте журнал регистрации на ошибки и конфликты блокировок
Шаг 4. Разберитесь с блокировками
Блокировки — самая частая причина ситуации «всё висит, хотя сервер не загружен». Когда один пользователь проводит крупный документ или запускается обмен, другие ждут освобождения записей. Внешне это выглядит как зависшая программа при нулевой загрузке процессора.
Диагностика: в MS SQL Server используйте Activity Monitor или запросы к системным представлениям (sys.dm_tran_locks, sys.dm_os_waiting_tasks), в консоли кластера 1С смотрите список соединений и их активность. Журнал регистрации с включённым событием блокировок покажет, какие объекты конфликтуют чаще всего.
Типовые меры: убедиться, что в свойствах базы в консоли кластера включён управляемый режим блокировок (для современных конфигураций это стандарт), сократить длительность транзакций (не держать открытые формы документов в режиме редактирования), разнести массовые операции по времени. Если блокировки возникают на конкретном регистре — это повод передать анализ разработчику, возможно, нужна оптимизация кода проведения.
Шаг 5. Оптимизируйте СУБД
Настройки СУБД «по умолчанию» часто не рассчитаны на нагрузку 1С. Для MS SQL Server проверьте: ограничение памяти сервера (оставьте ОС и платформе 1С минимум несколько гигабайт, иначе SQL заберёт всю память), модель восстановления базы (для большинства случаев достаточно Simple, если нет требований к точечному восстановлению), авторасширение файлов (лучше фиксированный прирост в мегабайтах, а не в процентах).
Регулярное обслуживание обязательно: обновление статистики и перестроение (или реорганизация) индексов. После больших загрузок данных, свёртки базы или обновления конфигурации статистика устаревает, и оптимизатор строит плохие планы запросов — типичный симптом: «вчера отчёт формировался за секунды, сегодня — минуты».
Размещайте файлы данных и журнал транзакций на разных физических дисках, если это возможно. Следите за размером tempdb — при интенсивной работе отчётов tempdb активно используется, и её размещение на быстром диске даёт заметный эффект.
Симптом «отчёт внезапно стал формироваться в десятки раз дольше без изменений в системе» почти всегда лечится обновлением статистики по таблицам, участвующим в запросе. Это безопасная операция, которую можно выполнить в рабочее время.
Шаг 6. Проверьте клиентскую сторону и файловые базы
Если тормозит только одно рабочее место: проверьте, каким клиентом работает пользователь (тонкий, толстый, веб), нет ли у него открытых десятков окон, обновлён ли антивирус и не сканирует ли он каталог с кэшем 1С. Иногда помогает очистка кэша метаданных клиента — удаление папок кэша в профиле пользователя (%APPDATA%\1C и %LOCALAPPDATA%\1C) при закрытой программе.
Файловая база на сетевом диске — самый слабый вариант для многопользовательской работы. При 5–10 одновременных пользователях и базе в несколько гигабайт тормоза практически гарантированы, и никакая настройка сервера это не исправит. Решение — переход на клиент-серверный режим (MS SQL, PostgreSQL) или на веб-сервер с публикацией базы.
Для файловой базы также важно: размещать её на быстром локальном диске сервера (не на NAS с медленным диском), исключить папку базы из антивируса и индексации Windows, регулярно выполнять тестирование и исправление с реиндексацией в нерабочее время.
Сравнение вариантов размещения базы
Подходит для 1–5 пользователей и небольшого объёма. При росте числа пользователей и базы тормозит из-за сетевых блокировок файла
Стандарт для 10+ пользователей и больших баз. Требует администрирования СУБД, но снимает ограничения файлового режима
Удобно для удалённых пользователей и филиалов, но не решает проблему производительности самой базы
Шаг 7. Найдите тяжёлые запросы и лишние данные
Если тормозит конкретная операция, используйте замер производительности (в конфигураторе: Отладка → Замер производительности). Он покажет, какие строки кода и запросы занимают больше всего времени. Запросы, обращающиеся к огромным таблицам без индексов, — прямая задача для разработчика.
Проверьте объём накопленных данных: журналы документов за много лет, гигантские регистры сведений, неочищенные истории обменов, версии объектов. Свертка базы (обрезание старых периодов с переносом остатков) и удаление помеченных объектов часто дают самый заметный эффект для старых баз.
Также обратите внимание на журнал регистрации: при работе годами без очистки он вырастает до десятков гигабайт и замедляет запись событий. Настройте сокращение журнала (хранить события за ограниченный период) через конфигуратор.
Шаг 8. Проверьте результат после изменений
После каждого изменения измеряйте эффект: время выполнения проблемной операции до и после. Не меняйте несколько настроек одновременно — иначе не поймёте, что именно помогло, и не сможете откатить лишнее.
Контрольные точки: отчёт, который формировался 10 минут, должен формироваться за секунды–десятки секунд; проведение документа не должно занимать больше нескольких секунд; в мониторе ресурсов сервера не должно быть устойчивой 100%-й загрузки CPU и дисковой очереди в часы пик.
Как проверить результат
Сопоставимо с нормой для вашего объёма данных, стабильно в течение дня
Время «плавает» от секунд до минут без видимой причины
CPU ниже 70–80%, есть свободная память, дисковая очередь низкая
Устойчивые 100% CPU, память исчерпана, активная подкачка
Кратковременные, не влияют на пользователей
Цепочки ожиданий, жалобы на «зависание» при проведении
Нет повторяющихся ошибок заданий и конфликтов
Регулярные ошибки, таймауты, взаимоблокировки
Если после всех шагов тормоза сохраняются, а замеры показывают, что время уходит внутри конкретных запросов конфигурации, — дальнейшая работа относится к зоне разработчика: оптимизация запросов, добавление индексов, пересмотр алгоритмов проведения. Самостоятельно вмешиваться в код типовой конфигурации без опыта не стоит: это усложнит обновления и может нарушить логику учёта.
Что важно запомнить
Действуйте по цепочке: локализуйте проблему (все или один, всё или одна операция), проверьте сервер и регламентные задания, разберитесь с блокировками и настройками СУБД, измеряйте эффект каждого изменения. Файловый режим при росте пользователей заменяйте клиент-серверным, а тяжёлые запросы передавайте разработчику.
Частые вопросы
1С тормозит только утром, когда все заходят в систему. Что делать?
Это типичная картина нехватки ресурсов при пиковой нагрузке или массового запуска фоновых заданий при старте. Проверьте, не запланированы ли обмены и синхронизации на время начала рабочего дня, посмотрите загрузку дисков сервера именно в этот период и убедитесь, что резервное копирование не выполняется утром.
Поможет ли переход на SSD, если 1С работает на обычных дисках?
Для базы данных — почти всегда да, это одно из самых эффективных апгрейдов: СУБД критична к скорости случайного чтения и записи. Но если причина тормозов в блокировках или неоптимальных запросах, SSD лишь частично сгладит симптомы, не устранив причину.
После обновления конфигурации 1С стала работать медленнее. Куда смотреть?
Сначала обновите статистику и перестройте индексы в СУБД — после массовых изменений данных планы запросов часто устаревают. Затем убедитесь, что завершились все отложенные обработчики обновления (они могут работать в фоне и нагружать базу). Если не помогло — сделайте замер производительности проблемной операции и сравните с типовым поведением.
База весит 50 ГБ, это много? Нужно ли её сворачивать?
Сам по себе размер не является проблемой — клиент-серверные базы успешно работают и с сотнями гигабайт. Проблемой становится то, что запросы сканируют лишние данные. Если тормозят отчёты по текущему периоду из-за объёма старых данных и старые периоды не нужны для оперативной работы, свёртка оправдана, но выполняйте её только с резервной копией и в нерабочее время.
Антивирус действительно может так сильно тормозить 1С?
Да, особенно на сервере: проверка каждой операции записи в файлы базы и журнала транзакций в реальном времени многократно увеличивает время дисковых операций. Добавьте каталоги базы данных, tempdb, временных файлов платформы и кэша клиентов в исключения — это безопасно при условии, что остальная система остаётся под защитой.
Можно ли ускорить 1С без привлечения специалиста?
Базовые меры доступны администратору без глубокой специализации: исключения в антивирусе, перенос регламентных заданий на ночь, очистка кэша клиентов, обновление статистики, сокращение журнала регистрации, удаление помеченных объектов. Настройку СУБД, анализ блокировок и оптимизацию запросов лучше доверить специалисту — ошибки там дороже.