Рано или поздно любой системный администратор или специалист 1С сталкивается с неприятной ситуацией: пользователи одной из удаленных точек начинают жаловаться на регулярные вылеты из базы с ошибкой «Потеряна связь с базой...» или бесконечным «зависанием» процессов. При этом на других точках все работает стабильно, а локальный провайдер уверяет, что с его стороны «все идеально». Выясним истинную причину проблемы, разберем методы детальной диагностики сетевого канала и рассмотрим тонкие настройки веб-серверов Apache и IIS, а также самого клиента 1С, которые помогут стабилизировать подключение.
В процессе обсуждения сетевых проблем часто звучит совет запустить непрерывный пинг с большим размером пакета — например, 9 Кбайт. Разберем, почему это заблуждение. Использование Jumbo Frames (пакетов размером 9000 байт) допустимо только внутри локальных сетей при условии, что абсолютно все коммутаторы на пути поддерживают этот режим. В глобальной сети Интернет стандартный размер MTU (Maximum Transmission Unit) составляет 1500 байт. Если на пути трафика есть VPN-туннели, этот показатель падает еще ниже — до 1400–1450 байт.
Если отправить пакет больше стандартного MTU с установленным флагом запрета фрагментации, он гарантированно потеряется на первом же маршрутизаторе провайдера. Проанализируем реальный предел MTU на проблемном канале, выполнив команду со специальными ключами:
ping [IP-адрес_сервера] -f -l 1472
Здесь параметр -f запрещает фрагментацию пакета, а параметр -l 1472 задает размер полезных данных (1472 байта данных + 28 байт заголовков IP/ICMP дают ровно 1500 байт). Если в ответ мы получаем сообщение «Требуется фрагментация пакета, но установлен запрещающий флаг», значит, на каком-то узле провайдера или на роутере клиента максимальный размер пакета занижен. Постепенно уменьшаем значение параметра -l (например, до 1450, 1400, 1350) до тех пор, пока пакеты не начнут стабильно проходить. Если рабочее значение оказывается ниже 1350, это серьезный повод заставить провайдера проверить настройки MSS Clamping на его оборудовании.
Обычная команда ping показывает лишь факт наличия или отсутствия связи в конкретную секунду. Для сбора доказательной базы для провайдера нам потребуется утилита WinMTR. Она объединяет в себе функционал ping и traceroute, отправляя запросы непрерывно и фиксируя процент потерь на каждом промежуточном узле (хопе).
Запустим тест в фоновом режиме на проблемном рабочем месте и дадим ему поработать хотя бы 30–60 минут (а лучше в течение всего рабочего дня). При анализе результатов обратим внимание на следующие колонки:
Для детальной оценки стабильности и скорости сетевого подключения отлично подходит кроссплатформенная утилита iperf3. Она позволяет протестировать пропускную способность канала не абстрактными файлами, а непрерывным TCP- или UDP-потоком данных непосредственно до вашего сервера. Для проведения теста запустим утилиту на сервере 1С в режиме прослушивания порта:
iperf3 -s
На клиентской машине запустим утилиту в режиме генерации трафика, указав IP-адрес сервера:
iperf3 -c [IP_адрес_сервера] -t 60
Этот тест в течение 60 секунд будет нагружать канал. Если в процессе теста мы увидим сильные просадки скорости (вплоть до нуля) или большое количество повторно отправленных пакетов (Retr), это будет свидетельствовать о нестабильной физической линии связи на проблемной точке.
Очень часто вылеты происходят не из-за физического обрыва кабеля, а потому, что веб-сервер считает соединение неактивным и принудительно его закрывает при малейшем сбое. Настроим параметры удержания сессий на стороне сервера.
Для публикации на базе Apache:
Откроем конфигурационный файл httpd.conf веб-сервера Apache и найдем или добавим параметры тайм-аутов. По умолчанию значение KeepAliveTimeout может быть слишком малым (около 5 секунд), что заставляет сервер постоянно разрывать неактивные TCP-соединения. Увеличим лимиты, добавив в конфигурационный файл строки:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 60
Timeout 300
Также откроем файл публикации базы default.vrd (обычно он расположен в каталоге публикации базы на веб-сервере) и проверим параметр SessionTimeout в элементе point. По умолчанию он может отсутствовать или иметь слишком маленькое значение. Установим его принудительно, например, на 10 минут (600 секунд):
<point ... sessionTimeout="600">
Для публикации на IIS (Internet Information Services):
По умолчанию пул приложений IIS настроен на автоматическое засыпание при отсутствии активности пользователя (параметр Idle Time-out равен 20 минутам). Кроме того, пул может перезапускаться по расписанию в течение дня, что приводит к моментальному выбросу всех пользователей из базы с ошибкой связи. Откроем консоль управления IIS, перейдем в «Пулы приложений», выберем пул вашей публикации, зайдем в «Дополнительные параметры» и настроим параметры:
0 (отключено).Если качество интернета на точке оставляет желать лучшего и провайдер оперативно помочь не может, мы можем оптимизировать работу самого клиента 1С, сделав его более устойчивым к сетевым задержкам.
Откроем окно запуска 1С на проблемном компьютере, выберем нужную информационную базу и нажмем кнопку «Изменить». Нажмите кнопку «Далее» до окна с параметрами запуска. Найдем опцию «Скорость соединения» и переключим ее в режим «Низкая».
При включении этого режима платформа 1С кардинально меняет логику обмена данными с веб-сервером:
Чтобы окончательно доказать руководству или провайдеру, что обрывы происходят на физическом уровне сети, настроим сбор Технологического журнала (ТЖ) на проблемном компьютере. Для этого в каталоге установки платформы (или в общей папке настроек 1С) создадим конфигурационный файл logcfg.xml с инструкцией фиксировать только системные исключения и ошибки сетевого обмена:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log history="24" directory="C:\1C_Logs">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="All"/>
</log>
</config>
При очередном вылете программы откроем сформированные файлы логов в папке C:\1C_Logs. Если мы увидим там зафиксированные события исключений EXCP, содержащие системные ошибки операционной системы типа Connection reset by peer или WinSock Error 10054 (An existing connection was forcibly closed by the remote host), у нас на руках будут неопровержимые системные доказательства того, что соединение было разорвано внешней сетевой средой еще до того, как на это отреагировала платформа 1С. Для быстрого анализа и группировки таких записей можно использовать внешний отчет для анализа ошибок технологического журнала.
В некоторых случаях виновником сетевых обрывов является не провайдер, а локальное программное обеспечение на рабочем месте пользователя. Обратим внимание на два важных аспекта:
1. Сетевые экраны и антивирусы с веб-аналитикой.
Современные антивирусные продукты очень любят перехватывать входящий и исходящий HTTPS-трафик на лету, расшифровывать его для анализа содержимого и заново шифровать перед отправкой. Если файл ответа от 1С весит достаточно много, антивирус может задержать его обработку на время, превышающее таймаут ожидания платформы. Соединение разорвется. Обязательно добавим адрес публикации нашей базы 1С в исключения локального брандмауэра и антивируса (в частности, отключим для этого адреса проверку SSL/HTTPS-трафика).
2. Приоритет протокола IPv6 в Windows.
Операционная система Windows по умолчанию отдает приоритет протоколу IPv6 над классическим IPv4. Если провайдер на проблемной точке предоставляет некорректные настройки IPv6, запросы к веб-серверу 1С будут сначала пытаться пройти по IPv6, зависать по таймауту, и только потом система переключится на IPv4. Это выглядит для пользователя как периодическое «залипание» интерфейса с последующим отвалом базы. Рекомендуется зайти в свойства сетевого адаптера на проблемном ПК и просто снять галочку с компонента «IP версии 6 (TCP/IPv6)».