Проверка 1С:Предприятия по цепочке: от рабочего места до сервера и СУБД

Проверить работоспособность 1С проще всего по цепочке: запустить базу на одном компьютере с ключом /ClearCache, затем проверить доступ к папке базы или к портам сервера 1540, 1541 и 1560-1591, посмотреть кластер в консоли и прогнать Тестирование и исправление в Конфигураторе. Если на каждом звене всё в порядке, остаётся производительность СУБД и разбор журналов.

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

С чего начать: локализовать сбой

Первый вопрос — масштаб. От ответа зависит, куда смотреть дальше.

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

Проверка рабочего места пользователя

Начните с клиента — это быстро и безопасно.

1. Версия платформы. Откройте Справка → О программе (в интерфейсе «Такси» — через меню с иконкой вопроса или главное меню). Номер версии клиента в клиент-серверном варианте должен совпадать с версией сервера 1С.
2. Кэш. Запустите базу из ярлыка с ключом /ClearCache или нажмите Настройка в окне запуска и проверьте путь к базе. Ключ очищает кэш метаданных на этом компьютере — это лечит странные ошибки после обновления конфигурации.
3. Другой пользователь на том же ПК. Если под другой учётной записью Windows база открывается, проблема в профиле: кэш в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8, сохранённые настройки, список баз ibases.v8i.
4. Тот же пользователь на другом ПК. Если и там ошибка, дело не в компьютере, а в правах пользователя 1С или в данных.

Отдельно проверьте антивирус. Если он сканирует папку файловой базы или каталог кэша в реальном времени, 1С работает заметно медленнее. Каталог базы и рабочие каталоги сервера лучше добавить в исключения — по согласованию с тем, кто отвечает за безопасность.

Сеть, порты и доступ к файлам базы

Здесь всё зависит от варианта работы.

Файловая база

Файловая база — это один файл 1Cv8.1CD в сетевой папке. Проверка:

• 📁 откройте эту папку в проводнике с компьютера пользователя под его учёткой;
• ✍️ создайте и удалите в ней тестовый файл — нужны права на изменение, а не только на чтение;
• 🔒 проверьте, не остался ли файл 1Cv8.1CL после аварийного завершения при том, что никто не работает .

Файловую базу по сети лучше держать на обычной общей папке Windows с прямым доступом. Работа через VPN с плохим каналом — частая причина «зависаний» и повреждения файла.

Клиент-серверная база

Клиент обращается к агенту сервера (порт 1540), затем к менеджеру кластера (1541) и к рабочим процессам из диапазона 1560-1591. Диапазон задаётся в свойствах рабочего сервера, у вас он может быть другим.

Проверить доступность портов с рабочего места можно из PowerShell:

Test-NetConnection srv1c -Port 1540
Test-NetConnection srv1c -Port 1541
Test-NetConnection srv1c -Port 1560

TcpTestSucceeded : True означает, что порт открыт. Если False — смотрите брандмауэр на сервере и сетевое оборудование.

Ещё одна классическая причина — имя сервера. Клиент должен разрешать имя сервера 1С так же, как оно записано в кластере. Если ping srv1c не отвечает по имени, а по IP отвечает, пропишите имя в DNS или в файле hosts.

Диагностика сервера 1С и кластера

На сервере первым делом проверьте службу Агент сервера 1С:Предприятия 8.3 в services.msc: она должна быть в состоянии «Выполняется». Если служба стоит, посмотрите журнал Windows «Приложение» — там обычно видно причину остановки.

Дальше откройте консоль администрирования серверов 1С или используйте rac через службу ras:

rac cluster list
rac session list --cluster=<id кластера>

Подставьте идентификатор из вывода первой команды. Если на кластере задан администратор, понадобятся параметры авторизации — их синтаксис смотрите в rac help.

Что смотреть в кластере:

• ⚙️ Рабочие процессы: сколько запущено, сколько памяти занимают, нет ли процесса rphost с постоянно растущей памятью;
• 👥 Сеансы: зависшие сеансы с давним временем последней активности;
• 🔑 Лицензии: rac session list --licenses покажет, какой сеанс какую лицензию занял — полезно при ошибке нехватки лицензий;
• 🧱 Блокировки: при массовых ожиданиях — кто держит управляемую блокировку.

Если консоль не открывается вовсе, а служба работает, частая причина — не зарегистрирована библиотека консоли после установки новой версии платформы. Помогает перерегистрация radmin.dll от имени администратора из каталога bin нужной версии: regsvr32 radmin.dll.

Тест базы и проверка СУБД

Тестирование и исправление информационной базы

Главный встроенный инструмент — Конфигуратор → Администрирование → Тестирование и исправление. Ему нужен монопольный доступ: всех пользователей придётся отключить.

Порядок:

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

Тот же тест можно запустить из командной строки, например по расписанию ночью:

"C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe" DESIGNER /F"D:\Base\Buh" /N"Админ" /P"пароль" /IBCheckAndRepair -LogIntegrity -TestOnly /Out"D:\Logs\check.txt"

Номер версии в пути подставьте свой. Ключ /Out пишет результат в файл — его удобно проверять утром.

Для файловой базы есть ещё утилита chdbfl.exe в каталоге bin платформы. Она проверяет физическую целостность файла 1Cv8.1CD, когда база не открывается даже в Конфигураторе. Запускайте её на копии файла.

Проверка на стороне СУБД

В клиент-серверном варианте целостность самих таблиц проверяют средствами СУБД:

Если в MS SQL нет плана обслуживания, статистика устаревает, и запросы 1С со временем становятся медленнее. Это одна из самых частых причин «раньше было быстро».

Тестирование производительности 1С

Когда база работает, но медленно, нужны цифры, а не ощущения.

• 📊 Тест Гилёва — распространённый бесплатный тест: загружается как отдельная база, выдаёт условный балл однопоточной производительности. Полезен для сравнения: «до и после переезда», «сервер А против сервера Б».
• 🖥️ Монитор ресурсов Windows на сервере: загрузка процессора, очередь диска, свободная память. Длинная очередь диска с базой — признак медленного хранилища.
• 🗄️ Монитор активности в СУБД: какие запросы выполняются дольше всего и кто кого ждёт.

Тест Гилёва и тому подобные меряют однопоточную скорость. Ситуацию «тормозит, когда работают 30 человек» они не воспроизведут — там почти всегда виноваты блокировки или тяжёлые запросы, и их ищут через технологический журнал.

Ключи запуска для отладки

Ключи добавляют в ярлык после пути к 1cv8.exe или в поле «Дополнительные параметры запуска» в настройках базы в окне запуска.

Пример ярлыка для пользователя с очисткой кэша:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S"srv1c\buh" /ClearCache

Журнал регистрации и технологический журнал

Журнал регистрации

Это первое, что стоит открыть при ошибке на конкретной операции. Пути:

• в типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) — Администрирование → Обслуживание → Журнал регистрации;
• в Конфигураторе — Администрирование → Журнал регистрации.

Поставьте отбор по времени, которое записали в начале, и по уровню «Ошибка». В событии видны пользователь, компьютер, объект и полный текст исключения — часто этого достаточно, чтобы понять, что сломалось.

Если журнал пустой или видно только часть событий, проверьте Конфигуратор → Администрирование → Настройка журнала регистрации: там задаётся, какие события записывать. Файлы журнала хранятся в каталоге 1Cv8Log рядом с файловой базой или в рабочем каталоге кластера для серверной.

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

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

Простейшая настройка — собирать исключения и долгие вызовы:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\TechLog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="CALL"/>
      <gt property="duration" value="50000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Следите за свободным местом на диске: технологический журнал с широким отбором за день занимает гигабайты. Включайте его на время разбора и выключайте, переименовав или удалив logcfg.xml. Параметр history задаёт, сколько часов хранить логи.

Если проблема не локализуется

Бывает, что каждое звено по отдельности в порядке, а сбой повторяется. Что ещё проверить:

• 🕐 Время на сервере и клиентах. Расхождение в несколько минут ломает авторизацию и обмены.
• 🧩 Расширения конфигурации . Отключите их по одному в Администрирование → Печатные формы, отчеты и обработки → Расширения и проверьте, ушла ли ошибка.
• 🔄 Обновления Windows и антивируса. Сбой «вчера работало» часто совпадает с ночной установкой обновлений.
• 🧪 Копия базы на другом сервере. Разверните выгрузку .dt на тестовом сервере. Ошибка повторилась — дело в данных или конфигурации, нет — в инфраструктуре.

Последний способ медленный, но даёт однозначный ответ, на чьей стороне проблема.

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