Рассмотрим распространенную и крайне коварную техническую проблему, с которой часто сталкиваются системные администраторы и разработчики при переходе на управляемые формы и тонкий клиент 1С. Ситуация выглядит следующим образом: большая часть коллектива работает стабильно и быстро, но у нескольких конкретных сотрудников запуск программы занимает до трех минут, а открытие любых справочников и документов сопровождается сильными зависаниями.
При этом аппаратное обеспечение компьютеров и пропускная способность локальной сети полностью исправны. Более того, если проблемный пользователь садится за компьютер своего коллеги, у которого всё работает быстро, 1С у него под его учетной записью продолжает тормозить. Напротив, если беспроблемный пользователь заходит под своим именем на ПК отстающего сотрудника — программа работает отлично.
Разберем по шагам ключевой симптом, упомянутый в ходе обсуждения: если мы создаем совершенно новую учетную запись в базе данных, она запускается быстро. Но стоит нам переименовать её в имя проблемного сотрудника, как она моментально начинает тормозить. Попытка вернуть имя обратно уже не помогает. Этот парадокс однозначно указывает на то, что источник проблемы находится не на клиентских ПК и не в локальной сети, а непосредственно внутри информационной базы и механизмов платформы 1С.
В этой статье мы подробно проанализируем причины такого поведения системы и разберем практические методы устранения этой неисправности.
Вся информация о пользовательском интерфейсе (настройки форм, расположение колонок, отборы, условное оформление динамических списков, истории поиска) хранится непосредственно в таблицах базы данных (в SQL-варианте за это отвечает таблица _systemsett или объект SystemSettingsStorage).
Когда вы переименовываете нового пользователя в имя старого (проблемного), платформа автоматически связывает его учетную запись со старыми записями в таблице настроек базы данных по строковому представлению имени. Если эти настройки повреждены или содержат избыточные данные, тонкий клиент начинает зависать на этапе их чтения и рендеринга.
Для решения этой проблемы выполним следующие действия:
Если штатная очистка через интерфейс не принесла результатов, выполним программное удаление системных настроек с помощью внешней обработки. Напишем и запустим следующий код:
ИмяПользователяДляОчистки = "ПроблемныйПользователь";
ХранилищеСистемныхНастроек.Удалить(Неопределено, Неопределено, ИмяПользователяДляОчистки);
ХранилищеОбщихНастроек.Удалить(Неопределено, Неопределено, ИмяПользователяДляОчистки);
ХранилищеНастроекДанныхФорм.Удалить(Неопределено, Неопределено, ИмяПользователяДляОчистки);
Этот код принудительно очистит все возможные системные кэши настроек конкретного пользователя непосредственно в таблицах базы данных.
Одной из наиболее частых причин долгого запуска тонкого клиента (до 2–3 минут) является сохраненный кэш настроек печати табличных документов. Платформа 1С записывает в хранилище системных настроек имя принтера, который пользователь использовал по умолчанию.
Если этот принтер был сетевым и его отключили, переименовали или физически убрали из сети, то при каждом старте системы или при формировании любых печатных форм тонкий клиент будет пытаться его опросить. В этот момент программа уходит в глубокое зависание, ожидая ответа (сетевого таймаута) от операционной системы. Это может занимать от 30 до 180 секунд на каждый запрос.
Чтобы исправить это, необходимо очистить настройки печати для проблемных учетных записей или временно отключить перенаправление принтеров в сессиях пользователей, чтобы сбросить старые привязки.
Выясним точную причину зависания с помощью встроенного отладчика 1С. Для этого нам понадобится запустить замер производительности в момент входа проблемного пользователя.
Выполним следующие шаги для настройки отладки:
-debug в строке запуска службы сервера).Проанализируем полученную таблицу замера. Особое внимание уделим колонке «Число строк» и «Время (чистое)». Если зависание происходит на серверных процедурах ПриНачалеРаботыСистемы или при получении прав, замер покажет конкретную строку кода, на которой спотыкается система.
Иногда в процессе тестирования или разработки администраторы случайно включают отладочные механизмы, имитирующие плохие каналы связи. Проверим этот параметр у проблемных пользователей.
Для этого в режиме «1С:Предприятие» откроем меню Сервис — Параметры и найдем поле Имитировать задержку вызова сервера. Убедимся, что значение в этом поле равно 0. Если там установлено отличное от нуля значение, тонкий клиент будет искусственно задерживать каждый сетевой пакет на указанное количество секунд, имитируя медленное соединение.
Обратим внимание на успешный практический опыт решения этой проблемы, описанный администратором на форуме. Решить проблему помог следующий алгоритм:
ПолныеПрава.ПолныеПрава, вернув стандартные ограниченные роли.Выясним, почему этот метод сработал. Платформа 1С для оптимизации проверки прав доступа строит на сервере специальные кэш-таблицы ограничений (особенно если используются механизмы RLS). При изменении ролей на «Полные права» платформа отключает проверку ограничений и принудительно перезаписывает часть параметров в _systemsett стандартными значениями.
Когда полные права отзываются обратно, сервер 1С вынужден заново сгенерировать и перестроить таблицы ограничений для этих учетных записей, что устраняет накопившиеся ошибки кэша прав и возвращает скорость работы тонкого клиента к нормальным показателям.