Почему 1С долго открывается под конкретным пользователем при работе через интернет и как это исправить?

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

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

Суть проблемы: почему 1С зависает до начала выполнения кода?

Когда мы запускаем клиентское приложение 1С:Предприятие, еще до выполнения первой строчки программного кода конфигурации (которая обычно находится в обработчике события ПередНачаломРаботыСистемы модуля управляемого приложения), платформа обязана подготовить и инициализировать рабочее окружение пользователя. Для этого она обращается к базе данных за пользовательским профилем.

Рассмотрим ключевые технические факторы, которые приводят к возникновению задержки:

1. Таблица dbo.Files и файлы .pfl: Платформа 1С хранит индивидуальные профили и системные настройки пользователей непосредственно в базе данных. В клиент-серверном режиме работы (на MS SQL Server или PostgreSQL) эти данные записываются в системную таблицу dbo.Files. Каждому пользователю соответствует бинарный файл настроек с именем вида <Идентификатор_Пользователя>.pfl (например, 071523a4-516f-4fce-ba4b-0d11ab7a1893.pfl).
2. Что хранится в профиле пользователя? В этом бинарном файле сохраняются индивидуальные настройки динамических списков (пользовательские отборы, сортировки, условное оформление реестров документов), персональные параметры отображения форм (размеры и положение окон, видимость и ширина колонок табличных частей), а также локальный кэш структуры некоторых метаданных.
3. Проблема «раздувания» настроек: За несколько лет активной работы активный пользователь (особенно бухгалтер или администратор) открывает сотни различных форм, настраивает десятки отчетов и списков. Файл .pfl постепенно накапливает устаревшие и кэшированные данные. Его размер может вырасти с нескольких килобайт до 15–30 мегабайт и более.
4. Влияние интернет-канала: В локальной сети (LAN на скорости 1 Гбит/с) скачивание файла размером 20 МБ занимает сотые доли секунды, поэтому администраторы и пользователи даже не догадываются о раздутом профиле. Но когда сервер переносится в интернет, скорость скачивания ограничивается пропускной способностью канала и сетевыми задержками (пингом). При скорости интернета в 10 Мбит/с скачивание файла размером 20 МБ с учетом накладных расходов протокола 1С может занимать до 40–50 секунд. Все это время пользователь наблюдает заставку запуска, а интернет-канал на его компьютере полностью утилизируется.
5. Почему не помогает стандартная очистка кэша? Локальная очистка кэша на компьютере пользователя (удаление папок из %AppData%\1C\1Cv8) не решает проблему, так как бинарный профиль хранится на сервере в СУБД. Также стандартная процедура очистки настроек внутри режима «1С:Предприятие» («Очистить настройки» в меню администратора) удаляет записи из таблиц пользовательских настроек (таких как _SystemSettings, _RepSettings), но при этом сам файл-контейнер .pfl в таблице dbo.Files часто остается прежнего размера или содержит поврежденный бинарный кэш, который платформа продолжает скачивать при каждом старте.

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

Пошаговое руководство по исправлению проблемы в СУБД

Для выполнения этой процедуры потребуются права администратора СУБД (например, в MS SQL Server Management Studio или pgAdmin для PostgreSQL). Перед началом любых манипуляций с базой данных обязательно создайте резервную копию (бэкап) базы данных!

Шаг 1. Определение уникального идентификатора (UUID) пользователя

Для начала нам необходимо выяснить, какой именно файл в таблице dbo.Files принадлежит проблемному пользователю. Нам нужен его уникальный идентификатор (UUID). Выяснить его можно двумя путями.

Способ А: Через запрос к СУБД. Подключимся к базе данных и выполним SQL-запрос к системной таблице пользователей 1С:

SELECT [ID], [Name] FROM [dbo].[v8users]

Найдем в колонке Name имя нашего проблемного пользователя и скопируем значение из колонки ID. Это и есть искомый UUID.

Способ Б: Через программный код в 1С. Если у нас есть возможность запустить внешнюю обработку или выполнить код в консоли кода, мы можем получить UUID пользователя программно с помощью следующего фрагмента:

ПользовательИнформБазы = ПользователиИнформационнойБазы.НайтиПоИмени("ИмяПроблемногоПользователя");
Если ПользовательИнформБазы <> Неопределено Тогда
    Сообщить("Имя: " + ПользовательИнформБазы.Имя + " | UUID: " + ПользовательИнформБазы.УникальныйИдентификатор);
КонецЕсли;

Предположим, полученный UUID равен: 071523a4-516f-4fce-ba4b-0d11ab7a1893.

Шаг 2. Удаление раздутого профиля в таблице dbo.Files

Теперь выполним удаление записи настроек данного пользователя из базы данных. Для этого в консоли СУБД запустим следующий запрос (замените UUID в запросе на полученный вами на предыдущем шаге):

-- Удаляем основной файл профиля пользователя
DELETE FROM [dbo].[Files] 
WHERE [FileName] = '071523a4-516f-4fce-ba4b-0d11ab7a1893.pfl'

-- Удаляем резервную копию профиля пользователя (если она существует)
DELETE FROM [dbo].[Files] 
WHERE [FileName] = '071523a4-516f-4fce-ba4b-0d11ab7a1893.pf_'

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

Шаг 3. Дополнительная очистка связанных системных таблиц настроек (при необходимости)

В некоторых случаях, если запуск стал быстрее, но задержка всё еще ощущается при переходе от авторизации к открытию начальной страницы (между процедурами ПередНачаломРаботыСистемы и ПриНачалеРаботыСистемы), рекомендуется очистить настройки отчетов и форм пользователя в других таблицах. В этих таблицах идентификатор пользователя хранится в бинарном формате binary(16).

Для этого переведем строковый UUID в бинарный вид (уберем дефисы и добавим префикс 0x), например: 0x071523a4516f4fceba4b0d11ab7a1893 (для MS SQL), и выполним очистку:

-- Очистка системных настроек форм пользователя
DELETE FROM [dbo].[_SystemSettings] WHERE [User] = 0x071523a4516f4fceba4b0d11ab7a1893

-- Очистка настроек отчетов пользователя
DELETE FROM [dbo].[_RepSettings] WHERE [User] = 0x071523a4516f4fceba4b0d11ab7a1893

-- Очистка общих настроек пользователя
DELETE FROM [dbo].[_CommonSettings] WHERE [User] = 0x071523a4516f4fceba4b0d11ab7a1893

Шаг 4. Сжатие базы данных и обслуживание индексов

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

Выполним реиндексацию таблицы настроек и освободим неиспользуемое пространство на диске (Shrink) средствами СУБД:

-- Перестроение индексов для таблицы файлов
ALTER INDEX ALL ON [dbo].[Files] REBUILD;
GO

-- Сжатие базы данных для возврата свободного места операционной системе (в примере имя базы: My1CDatabase)
DBCC SHRINKDATABASE (N'My1CDatabase');
GO

При использовании PostgreSQL вместо этих команд выполните операцию VACUUM FULL ANALYZE Files; через консоль pgAdmin или psql.

Рекомендации по предотвращению подобных проблем

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

1. Отказ от прямого TCP-подключения (толстый/тонкий клиент по сети): Самый надежный способ полностью исключить влияние размера профилей на скорость запуска — изменить технологию доступа. Переведите пользователей на работу через RDP (терминальный сервер) / RemoteApp либо опубликуйте базу на веб-сервере (IIS или Apache) и используйте веб-клиент / тонкий клиент через HTTP/HTTPS. При такой схеме тяжелые файлы настроек передаются внутри локальной сети сервера, а до пользователя доходят оптимизированные пакеты данных или графический интерфейс.
2. Регулярная очистка настроек штатными средствами: Назначьте административную процедуру периодического аудита настроек. В режиме 1С:Предприятие перейдите в меню Администрирование — Настройки пользователей и прав — Настройки пользователей. Здесь вы можете точечно очистить неиспользуемые настройки форм и отчетов для сотрудников, которые давно не работают с определенными разделами программы.
3. Контроль за изменениями интерфейса: Ограничивайте права рядовых пользователей на глобальное изменение форм, добавление сотен колонок в динамические списки и сохранение сложных нетиповых вариантов отчетов без производственной необходимости. Чем меньше индивидуальных изменений вносит пользователь в интерфейс, тем меньше весит его файл профиля в СУБД.

Применение описанной методики позволит оперативно решить проблему долгого входа в 1С без радикального удаления пользователей и сохранит стабильность работы системы в распределенной сетевой инфраструктуре.