Зависает и тормозит 1С 8.3: ищем виновника по шагам

· 10 мин

Содержание

1С чаще всего виснет по одной из пяти причин: не хватает ресурсов компьютера или сервера, медленная или нестабильная сеть, пользователи ждут друг друга на блокировках в базе, тяжёлый запрос или доработка в конфигурации, либо в этот момент работают фоновые задания. Определить, какая из них ваша, можно за 15–30 минут, если смотреть на симптомы, а не перезагружать всё подряд.

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

С чего начать: три вопроса до любых действий

Прежде чем что-то чистить и настраивать, ответьте себе на три вопроса. Они сразу сужают круг причин вдвое.

  1. У кого тормозит? У одного пользователя — смотрите его компьютер, кэш, профиль. У всех сразу — сервер, сеть, СУБД, фоновые задания.
  2. Когда тормозит? Постоянно — ресурсы или сеть. В определённые часы — регламентные задания, обмены, резервное копирование , закрытие месяца . Только при одновременной работе нескольких людей — блокировки.
  3. На чём тормозит? Весь интерфейс (медленно открываются формы, меню) — клиент, сеть, кэш. Конкретный отчёт или проведение документа — запрос, код, блокировки.
СимптомВероятная причинаКуда смотреть первым
Медленно у одного, у остальных нормальноКэш, профиль, ПК, антивирусКомпьютер пользователя
Медленно у всех с утра до вечераСервер, диск, сетьДиспетчер задач сервера
Тормозит в одно и то же времяРегламентные задания, бэкапРасписание заданий и бэкапа
Проведение «висит», потом ошибка блокировкиКонфликт блокировокКто ещё проводит документы
Один отчёт строится минутамиТяжёлый запрос, большой периодОтбор и настройки отчёта
Зависает после обновленияКэш, новые фоновые обработкиОчистка кэша, обработчики обновления

Когда тормозит железо: память, диск, процессор

Нехватка ресурсов даёт ровный, постоянный «тормоз» без ошибок. Проверка простая: откройте Диспетчер задач → Производительность и Монитор ресурсов (вызывается командой 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 файловая база тормозит всегда, а при обрыве связи может повредиться.

Что делать по сети:

  1. Проверьте связь до сервера: ping -t имя_сервера в течение пары минут. Потери пакетов и скачки задержки выше 5–10 мс в локальной сети — уже повод разбираться с оборудованием.
  2. Уберите Wi-Fi для рабочих мест с файловой базой. Кабель решает больше, чем любые настройки.
  3. Для удалённых сотрудников используйте терминальный доступ (RDP) или публикацию на веб-сервере, а не файловую базу через VPN.
  4. Проверьте разрешение имён: если клиент долго ищет сервер по имени, первое подключение затягивается. Помогает запись в 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С: в списке сеансов видно пользователя, компьютер и время начала.

🛠️ Как лечить:

  1. Перенесите тяжёлые операции (перепроведение, закрытие месяца, загрузку обменов) на вечер или ночь.
  2. Проверьте режим управления блокировкой в свойствах конфигурации. Типовые конфигурации на актуальных релизах работают в управляемом режиме; автоматический часто остаётся у старых самописных баз.
  3. Разбейте большой обмен или групповую обработку на порции.
  4. Если блокировки возникают в доработке — отдайте разработчику данные технологического журнала (см. раздел о диагностике).

Завершать «зависший» сеанс в консоли кластера можно, но пользователь потеряет несохранённые данные, а его транзакция откатится. Сначала свяжитесь с ним.

Тяжёлые запросы, доработки и состояние самой базы

Когда тормозит одна конкретная операция — отчёт, проведение, открытие формы списка, — причина почти всегда в данных и коде, а не в железе.

📊 Отчёты. Оборотно-сальдовая ведомость за 3 года по всем субконто без отборов будет строиться долго на любом сервере. Сократите период, поставьте отбор по организации или счёту, уберите лишние группировки. Если отчёт тормозит и с узким отбором — проблема в его запросе.

📋 Динамические списки. Форма списка документов с произвольной сортировкой по реквизиту табличной части или с десятком дополнительных колонок заставляет СУБД перебирать всю таблицу. Верните стандартную сортировку по дате и уберите лишние колонки через настройку списка.

🧩 Доработки и расширения. Подписка на событие, которая при записи каждого документа выполняет запрос к большому регистру, замедляет всё проведение. Признак: в чистой типовой копии базы та же операция идёт быстро. Временно отключите расширения (Администрирование → Печатные формы, отчёты и обработки → Расширения, флаг активности) на копии базы и сравните.

🗄️ Состояние базы на СУБД. Для MS SQL Server обязательны регулярные задания: обновление статистик и перестроение или реорганизация индексов. Без них планы запросов деградируют, и база, которая летала полгода назад, начинает тормозить без видимых причин. Для PostgreSQL то же делают VACUUM ANALYZE и настройка autovacuum.

🧹 Файловая база. Её стоит периодически проверять: Конфигуратор → Администрирование → Тестирование и исправление с флагом «Сжатие таблиц информационной базы». Для этой операции нужен монопольный доступ — все пользователи должны выйти. Сделайте копию базы перед запуском.

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

Фоновые задания, обмены и обновления

Зависания «по расписанию» — почти всегда работа фоновых процессов. Пользователь их не видит, но они делят с ним сервер и базу.

⏰ Что обычно запускается в фоне в типовых конфигурациях:

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

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

🛠️ Что можно сделать:

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

🔄 После обновления. Первые часы и даже сутки после обновления релиза база может работать медленнее: в фоне выполняются отложенные обработчики обновления, которые перезаписывают данные. Их ход виден в разделе Администрирование → Обслуживание → Результаты обновления программы. Дождитесь окончания, а не перезапускайте сервер посреди процесса.

🧽 Кэш клиента. Ещё одна частая причина тормозов после обновления платформы или конфигурации — устаревший кэш на компьютере пользователя. Запустите 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. Она включается в разделе Администрирование → Обслуживание. Через неделю замеров видно, какая операция и в какие дни деградировала, — это лучше любых субъективных жалоб.

Порядок сбора фактов для подрядчика:

Что собрать перед обращением к специалисту
Выполнено: 0 / 7

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

Почему 1С зависает только у одного пользователя?
Причина почти всегда на его стороне: устаревший кэш, переполненный профиль Windows, антивирус, слабый ПК или плохой сетевой кабель. Сравните: зайдите под тем же пользователем 1С с другого компьютера. Если там быстро — ищите проблему в самом ПК.
Помогает ли перезагрузка сервера 1С?
Временно — да, если рабочий процесс накопил много памяти. Но это лечит симптом. Ограничьте допустимый объём памяти рабочих процессов в свойствах рабочего сервера и выясните, какая операция её съедает. Перезагрузку делайте вне рабочих часов: все сеансы оборвутся.
Что быстрее: тонкий или толстый клиент?
При медленной сети тонкий клиент обычно работает лучше: по сети идут данные форм, а не вся логика. В файловой базе по сети разница меньше, потому что узкое место — чтение файла базы.
Сколько пользователей выдержит файловая база?
Комфортно — до 3–5 одновременных пользователей в проводной локальной сети при базе на SSD. Дальше растут блокировки и время ожидания, и разумнее переходить на клиент-серверный вариант.
Почему 1С тормозит после обновления платформы?
Чаще всего виноват старый кэш и работающие в фоне обработчики обновления конфигурации. Очистите кэш запуском с /ClearCache и дождитесь завершения обработчиков в разделе результатов обновления.