Ситуация, когда типовая конфигурация (например, «1С:Бухгалтерия») при открытии зависает на время от 2 до 15 минут практически у всех пользователей, встречается достаточно часто. При этом серверное оборудование может не показывать видимой нагрузки: очередь к дискам минимальна, оперативной памяти и ресурсов процессора достаточно, а сетевые потери отсутствуют. Разберем по шагам, где кроется скрытая причина подобных зависаний, как локализовать проблему системными утилитами и какие параметры кластера серверов 1С требуют обязательной корректировки.
В клиент-серверном варианте длительный запуск сеанса обычно означает, что клиентское приложение ожидает ответа от сервера при инициализации параметров сеанса, получении метаданных или выполнении процедур при старте системы. Проанализируем консоль администрирования кластера серверов 1С:
rhost.exe: Реакция сервера и Затрачено сервером. При нормальной штатной работе время реакции сервера составляет около 0.1 секунды. Если значения достигают нескольких секунд (от 1 до 8 секунд и выше), это свидетельствует о деградации производительности конкретного рабочего процесса.rhost.exe. Когда внутри одного процесса накапливается очередь блокирующих вызовов, все новые подключения (включая запуск клиентов другими пользователями) становятся в очередь ожидания.Для поиска истинной причины зависания процесса сервера применим системную утилиту Process Monitor (Procmon). Рассмотрим порядок действий на сервере приложений:
ragent.exe.Process Name is rhost.exe, исключив нерелевантные события файловой системы и реестра.В ходе такого анализа нередко обнаруживается, что рабочий процесс непрерывно отправляет тысячи запросов к удаленным сетевым каталогам или несуществующим файловым ресурсам (со статусами BAD NETWORK PATH, NAME NOT FOUND или PATH NOT FOUND). Если в конфигурации настроено регламентное задание (например, обмен файлами или выгрузка данных), обращающееся к недействительным сетевым путям каждые несколько минут, операционная система уходит в системный таймаут ожидания ответа по протоколу SMB/RPC. Поскольку рабочий процесс блокируется ожиданием ответа от несуществующего ресурса, формируется внутренняя очередь, которая задерживает старт пользовательских сеансов.
Чтобы исключить влияние ресурсоемких или сбойных баз на остальные информационные базы, а также предотвратить деградацию рабочих процессов при утечках памяти, выполним тюнинг параметров кластера и рабочего сервера.
В свойствах кластера информационных баз установим следующие значения:
86400 секунд (сутки) или 43200 секунд (12 часов), если в системе выполняется большое число объемных регламентных заданий. По умолчанию значение равно 0, что приводит к многонедельной работе процессов без освобождения фрагментированной памяти.20971520 КБ, что соответствует 20 ГБ) в зависимости от общего объема ОЗУ сервера.60 секунд. При превышении порога кластер выделит новый рабочий процесс, а старый будет плавно выведен из эксплуатации.60 секунд, чтобы завершенные процессы не занимали системные дескрипторы и память.В свойствах конкретного Рабочего сервера скорректируем распределение нагрузки:
rhost.exe.После локализации сбойных процессов через утилиты мониторинга выполним программные доработки:
КаталогОбмена = Новый Файл(ПутьККаталогу);
Если КаталогОбмена.Существует() Тогда
// Выполнение процедур обработки файлов
Иначе
ЗаписьЖурналаРегистрации("СетевойОбмен", УровеньЖурналаРегистрации.Предупреждение, , , "Каталог недоступен: " + ПутьККаталогу);
КонецЕсли;
Если серверная часть настроена оптимально, но клиентские приложения на рабочих станциях продолжают открываться с задержкой, выясним сетевые и платформенные факторы:
Завершающим этапом комплексной оптимизации времени запуска является устранение проблем с кэшированием метаданных:
AppData\Local\1C\1Cv8 и AppData\Roaming\1C\1Cv8 вызывают повторные запросы структур метаданных. Запуск клиента с ключом /ClearCache позволяет сбросить временные данные.1C:Enterprise Server Agent и очистка серверного кэша конфигураций (каталоги sncfg_...).CONFIG, PARAMS, FILES, а также системных настроек _SystemSettings.