Зависает и тормозит 1С 8.3: ищем виновника по шагам
Содержание
1С чаще всего виснет по одной из пяти причин: не хватает ресурсов компьютера или сервера, медленная или нестабильная сеть, пользователи ждут друг друга на блокировках в базе, тяжёлый запрос или доработка в конфигурации, либо в этот момент работают фоновые задания. Определить, какая из них ваша, можно за 15–30 минут, если смотреть на симптомы, а не перезагружать всё подряд.
Распространённое заблуждение — «1С тормозит, значит, нужен новый сервер». На практике зависание у одного пользователя при одном и том же отчёте почти никогда не лечится железом. Сначала поймите, кто тормозит, когда и на какой операции, — от этого зависит решение.
С чего начать: три вопроса до любых действий
Прежде чем что-то чистить и настраивать, ответьте себе на три вопроса. Они сразу сужают круг причин вдвое.
- У кого тормозит? У одного пользователя — смотрите его компьютер, кэш, профиль. У всех сразу — сервер, сеть, СУБД, фоновые задания.
- Когда тормозит? Постоянно — ресурсы или сеть. В определённые часы — регламентные задания, обмены, резервное копирование , закрытие месяца . Только при одновременной работе нескольких людей — блокировки.
- На чём тормозит? Весь интерфейс (медленно открываются формы, меню) — клиент, сеть, кэш. Конкретный отчёт или проведение документа — запрос, код, блокировки.
| Симптом | Вероятная причина | Куда смотреть первым |
|---|---|---|
| Медленно у одного, у остальных нормально | Кэш, профиль, ПК, антивирус | Компьютер пользователя |
| Медленно у всех с утра до вечера | Сервер, диск, сеть | Диспетчер задач сервера |
| Тормозит в одно и то же время | Регламентные задания, бэкап | Расписание заданий и бэкапа |
| Проведение «висит», потом ошибка блокировки | Конфликт блокировок | Кто ещё проводит документы |
| Один отчёт строится минутами | Тяжёлый запрос, большой период | Отбор и настройки отчёта |
| Зависает после обновления | Кэш, новые фоновые обработки | Очистка кэша, обработчики обновления |
Когда тормозит железо: память, диск, процессор
Нехватка ресурсов даёт ровный, постоянный «тормоз» без ошибок. Проверка простая: откройте Диспетчер задач → Производительность и Монитор ресурсов (вызывается командой resmon) в момент зависания.
💾 Диск. Самая частая аппаратная причина, особенно в файловом варианте. Если активность диска держится около 100%, а время отклика уходит в десятки миллисекунд — диск не справляется. Файловая база на HDD при 3–5 пользователях уже ощутимо тормозит. Перенос файла 1Cv8.1CD на SSD обычно даёт самый заметный эффект из всех доступных мер.
🧠 Оперативная память. Если свободной памяти почти нет и система активно пишет в файл подкачки — всё замедляется. На клиентском ПК для тонкого клиента и браузера хватает 8 ГБ, для толстого клиента с тяжёлыми отчётами лучше 16 ГБ. На сервере память делят службы 1С и СУБД: им нужно согласованное ограничение, иначе они вытесняют друг друга.
⚙️ Процессор. Для 1С важна частота ядра, а не число ядер: один запрос или проведение одного документа выполняется в основном в одном потоке. Сервер с 32 медленными ядрами может проводить документ дольше, чем офисный ПК с 4 быстрыми.
На сервере и рабочих станциях включите схему электропитания «Высокая производительность». В режиме экономии энергии процессор сбрасывает частоту, и 1С ощутимо проседает на коротких операциях.
🛡️ Антивирус. Он проверяет каждое обращение к файлу базы и к кэшу. Добавьте в исключения каталог с файловой базой, каталоги кэша пользователя и процессы 1С (1cv8.exe, 1cv8c.exe, на сервере — ragent.exe, rmngr.exe, rphost.exe). Исключения согласуйте с тем, кто отвечает за безопасность.
Сеть и подключение: почему 1С висит «по проводу»
Сетевые проблемы выглядят как случайные подвисания на 5–30 секунд, белое окно «Не отвечает» и обрывы с ошибкой соединения.
📡 Файловая база по сети — главный источник проблем. Когда база лежит в общей папке, каждый пользователь читает файл 1Cv8.1CD по сети блоками. Это работает при 2–5 пользователях в проводной локальной сети. По Wi-Fi или VPN файловая база тормозит всегда, а при обрыве связи может повредиться.
Что делать по сети:
- Проверьте связь до сервера:
ping -t имя_серверав течение пары минут. Потери пакетов и скачки задержки выше 5–10 мс в локальной сети — уже повод разбираться с оборудованием. - Уберите Wi-Fi для рабочих мест с файловой базой. Кабель решает больше, чем любые настройки.
- Для удалённых сотрудников используйте терминальный доступ (RDP) или публикацию на веб-сервере, а не файловую базу через VPN.
- Проверьте разрешение имён: если клиент долго ищет сервер по имени, первое подключение затягивается. Помогает запись в DNS или в файле
hosts.
🔌 Клиент-серверный вариант. Клиент подключается к агенту сервера (порт 1540), затем к менеджеру кластера (1541) и рабочим процессам — из диапазона портов, заданного в свойствах рабочего сервера (по умолчанию начинается с 1560). Если файрвол режет часть диапазона, подключение может проходить долго или с ошибкой. Откройте весь диапазон, а не только 1540–1541.
Если база больше 5–10 пользователей и работает в файловом режиме по сети, никакая настройка не вернёт ей нормальную скорость. Решение — переход на клиент-серверный вариант или хотя бы публикация через веб-сервер.
Блокировки в базе: когда пользователи ждут друг друга
Это причина «тормозит, когда работают все вместе». Один пользователь проводит документ, второй в тот же момент пытается изменить те же данные — и ждёт. Типичная картина: проведение висит около 20 секунд, затем появляется сообщение со словами Конфликт блокировок при выполнении транзакции или о превышении времени ожидания блокировки.
🔒 Почему возникают:
- массовое перепроведение документов днём, пока другие работают;
- закрытие месяца, расчёт себестоимости, расчёт зарплаты в рабочее время;
- обмен данными, который записывает тысячи объектов одной транзакцией;
- старая конфигурация или доработка с автоматическим режимом блокировок — он блокирует данные шире, чем нужно;
- долгая транзакция в собственном коде: внутри неё идут запросы, вывод сообщений или обращения к внешним сервисам.
🔍 Как проверить на сервере СУБД. В MS SQL Server посмотрите текущие сеансы и ожидания:
EXEC sp_who2;
Колонка BlkBy показывает, какой сеанс держит блокировку. В PostgreSQL то же видно в представлении активности:
SELECT pid, state, wait_event_type, wait_event, now() - query_start AS dlit, left(query, 80)
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY dlit DESC;
Узнать, какой именно пользователь 1С стоит за сеансом СУБД, удобнее через консоль администрирования серверов 1С: в списке сеансов видно пользователя, компьютер и время начала.
🛠️ Как лечить:
- Перенесите тяжёлые операции (перепроведение, закрытие месяца, загрузку обменов) на вечер или ночь.
- Проверьте режим управления блокировкой в свойствах конфигурации. Типовые конфигурации на актуальных релизах работают в управляемом режиме; автоматический часто остаётся у старых самописных баз.
- Разбейте большой обмен или групповую обработку на порции.
- Если блокировки возникают в доработке — отдайте разработчику данные технологического журнала (см. раздел о диагностике).
Завершать «зависший» сеанс в консоли кластера можно, но пользователь потеряет несохранённые данные, а его транзакция откатится. Сначала свяжитесь с ним.
Тяжёлые запросы, доработки и состояние самой базы
Когда тормозит одна конкретная операция — отчёт, проведение, открытие формы списка, — причина почти всегда в данных и коде, а не в железе.
📊 Отчёты. Оборотно-сальдовая ведомость за 3 года по всем субконто без отборов будет строиться долго на любом сервере. Сократите период, поставьте отбор по организации или счёту, уберите лишние группировки. Если отчёт тормозит и с узким отбором — проблема в его запросе.
📋 Динамические списки. Форма списка документов с произвольной сортировкой по реквизиту табличной части или с десятком дополнительных колонок заставляет СУБД перебирать всю таблицу. Верните стандартную сортировку по дате и уберите лишние колонки через настройку списка.
🧩 Доработки и расширения. Подписка на событие, которая при записи каждого документа выполняет запрос к большому регистру, замедляет всё проведение. Признак: в чистой типовой копии базы та же операция идёт быстро. Временно отключите расширения (Администрирование → Печатные формы, отчёты и обработки → Расширения, флаг активности) на копии базы и сравните.
🗄️ Состояние базы на СУБД. Для MS SQL Server обязательны регулярные задания: обновление статистик и перестроение или реорганизация индексов. Без них планы запросов деградируют, и база, которая летала полгода назад, начинает тормозить без видимых причин. Для PostgreSQL то же делают VACUUM ANALYZE и настройка autovacuum.
🧹 Файловая база. Её стоит периодически проверять: Конфигуратор → Администрирование → Тестирование и исправление с флагом «Сжатие таблиц информационной базы». Для этой операции нужен монопольный доступ — все пользователи должны выйти. Сделайте копию базы
перед запуском.
Перед тестированием и исправлением, переносом базы и любыми регламентными операциями на СУБД сделайте резервную копию. Режим исправления ошибок может удалить битые данные без возможности отката.
Фоновые задания, обмены и обновления
Зависания «по расписанию» — почти всегда работа фоновых процессов. Пользователь их не видит, но они делят с ним сервер и базу.
⏰ Что обычно запускается в фоне в типовых конфигурациях:
- обновление индекса полнотекстового поиска ;
- синхронизация данных с другими базами и сайтом;
- загрузка курсов валют и классификаторов;
- обмен с банком и ЭДО;
- обработчики после обновления конфигурации;
- резервное копирование средствами СУБД или сторонних программ.
Список и расписание открываются в разделе Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. Там видно, что выполняется прямо сейчас и сколько длилось прошлое выполнение.
🛠️ Что можно сделать:
- Найдите задание, время которого совпадает с жалобами пользователей.
- Перенесите его на нерабочее время или увеличьте интервал. Например, полнотекстовый индекс на большой базе разумно обновлять раз в сутки ночью, а не каждые несколько минут.
- Отключите задания, которыми не пользуетесь: нет обмена с сайтом — не нужна и его синхронизация.
- Проверьте, не пересекается ли резервное копирование с утренним началом работы.
🔄 После обновления. Первые часы и даже сутки после обновления релиза база может работать медленнее: в фоне выполняются отложенные обработчики обновления, которые перезаписывают данные. Их ход виден в разделе Администрирование → Обслуживание → Результаты обновления программы. Дождитесь окончания, а не перезапускайте сервер посреди процесса.
🧽 Кэш клиента. Ещё одна частая причина тормозов после обновления платформы или конфигурации — устаревший кэш на компьютере пользователя. Запустите 1С с параметром /ClearCache (в свойствах базы в окне запуска, поле «Дополнительные параметры запуска») или удалите вручную папки с именами-идентификаторами в каталогах:
%APPDATA%\1C\1cv8
%LOCALAPPDATA%\1C\1cv8
Перед ручной очисткой закройте все сеансы 1С на этом компьютере. Список баз хранится отдельно, в файле ibases.v8i, — его не трогайте, иначе пропадут подключения в окне запуска.
Диагностика зависаний: какими инструментами собрать факты
Если быстрые проверки не дали ответа, нужны данные. Без них разговор с подрядчиком или администратором сводится к «у нас всё тормозит».
🧰 Инструменты по уровням:
| Уровень | Инструмент | Что покажет |
|---|---|---|
| Компьютер, сервер | Диспетчер задач, resmon, perfmon | Загрузку ЦП, памяти, диска, сети |
| Сервер 1С | Консоль администрирования серверов 1С | Сеансы, рабочие процессы, их память |
| Сервер 1С | rac session list (подробности — rac help) | Сеансы из командной строки |
| СУБД | Монитор активности SQL Server, pg_stat_activity | Долгие запросы и ожидания |
| Конфигурация | Подсистема оценки производительности | Время ключевых операций по дням |
| Платформа | Технологический журнал | Блокировки, ошибки, долгие вызовы |
📝 Технологический журнал. Это главный инструмент для разбора блокировок и зависаний. Он включается файлом logcfg.xml в каталоге conf установленной платформы на сервере 1С (или на клиенте в файловом варианте). Пример настройки, которая пишет события блокировок и исключения:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\techlog" history="24">
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Параметр history задаёт, сколько часов хранить журнал. Платформа подхватывает файл без перезапуска, примерно в течение минуты.
Технологический журнал быстро растёт: на нагруженном сервере — гигабайты за час. Включайте его на время воспроизведения проблемы, следите за свободным местом на диске и удаляйте logcfg.xml после сбора данных.
📈 Оценка производительности. В типовых конфигурациях на БСП есть подсистема, которая замеряет время ключевых операций и считает показатель APDEX. Она включается в разделе Администрирование → Обслуживание. Через неделю замеров видно, какая операция и в какие дни деградировала, — это лучше любых субъективных жалоб.
Порядок сбора фактов для подрядчика:
Частые вопросы
Почему 1С зависает только у одного пользователя?
Помогает ли перезагрузка сервера 1С?
Что быстрее: тонкий или толстый клиент?
Сколько пользователей выдержит файловая база?
Почему 1С тормозит после обновления платформы?
/ClearCache и дождитесь завершения обработчиков в разделе результатов обновления.