Очень долго идет COM-соединение при подключении из 8.3 к 8.2
Здравствуйте!
Помогите решить такую пробему:
Есть две базы: БП 3.0 (на платформе 8.3) и самописная на платформе 8.2.
Есть обработка, которая переносит документы в БП 3.0 из самописной базы 8.2.
Обработка запускается в БП 3.0, и через com-соединение подключается к самописной базе.
БП 3.0 и самописная база расположены на разных серверах (хотя это не суть, т.к. пробовали и на одном сервере держать эти базы, и проблема все равно была).
Так вот, при запуске обработки в БП 3.0, сервер, на котором расположена БП 3.0, зависает полностью (подключение идет в процедуре с директивой &НаСервере).
На этом сервере расположены и другие (кроме БП 3.0) базы, висят и они.
В итоге все пользователи на этом сервере не могут работать.
Обработка выполняется от 20 секунд до 2-3 минут.
Мы определили, что более 90% этого времени занимает выполнение строки программного кода:
Сервер висит именно в этот момент!
Пробовали самописную базу перевести на платформу 8.3 в режиме совместимости - эта проблема ушла - подключение стало выполняться практически мгновенно, но появились другие ошибки, пришлось вернуть ее на 8.2.
На всякий случай, скажу, что на обоих серверах (1-й сервер с базой ОТКУДА подключаемся, 2-й сервер с базой К КОТОРОЙ подключаемся) стоят одновременно 8.3 и 8.2, причем 8.2 работает по нестандартным портам.
Вот строка подключения:
Админ, правда, говорит, что с портами это не связано (как это проверить?).
Провел еще такой эксперимент.
Создал две пустых базы - на 8.3 и на 8.2.
Стал пытаться подключиться из 8.3 к 8.2, пробуя базы в разных режимах (файловый и клиент-серверный) и замерять время подключения.
Вот результаты:
Подключение из 8.3 (файловая) к 8.2 (файловая): 2 сек.
Подключение из 8.3 (серверная) к 8.2 (файловая): 1-2 сек.
Подключение из 8.3 (файловая) к 8.2 (серверная): 5 сек.
Подключение из 8.3 (серверная) к 8.2 (серверная): 60-120 сек.
Т.е. тормозит, если обе базы серверные или только 8.2 серверная.
В чем может быть причина?
Помогите решить такую пробему:
Есть две базы: БП 3.0 (на платформе 8.3) и самописная на платформе 8.2.
Есть обработка, которая переносит документы в БП 3.0 из самописной базы 8.2.
Обработка запускается в БП 3.0, и через com-соединение подключается к самописной базе.
БП 3.0 и самописная база расположены на разных серверах (хотя это не суть, т.к. пробовали и на одном сервере держать эти базы, и проблема все равно была).
Так вот, при запуске обработки в БП 3.0, сервер, на котором расположена БП 3.0, зависает полностью (подключение идет в процедуре с директивой &НаСервере).
На этом сервере расположены и другие (кроме БП 3.0) базы, висят и они.
В итоге все пользователи на этом сервере не могут работать.
Обработка выполняется от 20 секунд до 2-3 минут.
Мы определили, что более 90% этого времени занимает выполнение строки программного кода:
База82 = V8COM.Connect(СтрокаСоединения); //подключение к базе на 8.2Сервер висит именно в этот момент!
Пробовали самописную базу перевести на платформу 8.3 в режиме совместимости - эта проблема ушла - подключение стало выполняться практически мгновенно, но появились другие ошибки, пришлось вернуть ее на 8.2.
На всякий случай, скажу, что на обоих серверах (1-й сервер с базой ОТКУДА подключаемся, 2-й сервер с базой К КОТОРОЙ подключаемся) стоят одновременно 8.3 и 8.2, причем 8.2 работает по нестандартным портам.
Вот строка подключения:
СтрокаСоединения = "Srvr=""ServerName:1741"";Ref=""BASE_test_82"";";Админ, правда, говорит, что с портами это не связано (как это проверить?).
Провел еще такой эксперимент.
Создал две пустых базы - на 8.3 и на 8.2.
Стал пытаться подключиться из 8.3 к 8.2, пробуя базы в разных режимах (файловый и клиент-серверный) и замерять время подключения.
Вот результаты:
Подключение из 8.3 (файловая) к 8.2 (файловая): 2 сек.
Подключение из 8.3 (серверная) к 8.2 (файловая): 1-2 сек.
Подключение из 8.3 (файловая) к 8.2 (серверная): 5 сек.
Подключение из 8.3 (серверная) к 8.2 (серверная): 60-120 сек.
Т.е. тормозит, если обе базы серверные или только 8.2 серверная.
В чем может быть причина?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Наблюдали похожую проблему. Приостановку работы других сеансов обошли установкой ограничения "1 соединение на рабочий процесс" в свойствах кластера базы-инициатора. При подключении к базам на 8.3 проблема вроде бы не наблюдалась. Еще может помочь добавление базы, к которой выполняется подключение в список баз пользователя ОС, под которым наблюдается долгое выполнение метода COnnect.
(2) Подскажите, пожалуйста, вы писали "Приостановку работы других сеансов обошли установкой ограничения "1 соединение на рабочий процесс" в свойствах кластера базы-инициатора" - не совсем понятно, за что отвечает данный параметр? И самое главное, не нашёл в консоли кластера подобную настройку, не могли бы вы по-шагово описать установку данного параметра, если можно? Спасибо!
(2) у меня следующая ситуация:
Версия платформы: 8.3.16.1224 (x64)
Подключение происходит в рамках одной машины и единого сервера 1С.
В качестве теста использовались следующие конфигурации: Комплексная автоматизация 2.4 (далее КА) и чистая конфигурация с пустой базой (далее ЧБ).
На строчке кода:
Серверная машина:
1.1 Подключения: КА1 (серверная) / ЧБ (файловая) -> КА2 (серверная) - 18-20 сек
1.2 Подключения: КА1 (серверная) / ЧБ (файловая) -> ЧБ (серверная) - 7 сек
1.3 Подключения: КА1 (серверная) / ЧБ (файловая) -> КА3 (файловая) - 9 сек
1.4 Подключения: КА1 (серверная) / ЧБ (файловая) -> ЧБ2 (файловая) - 5 сек
Развернул файловые базы на стационарной машине. Результат:
2.1 Подключение: ЧБ (файловая) -> ЧБ2 (файловая) - 1 сек
2.2 Подключение: ЧБ (файловая) -> КА (файловая) - 4 сек
1. Не могу понять, с чем может быть связана такая разница в пунктах 1.4 и 2.1, если серверная машина мощнее стационарной в разы?
2. Из анализа получения внешних соединений на серверной машине задержка всегда больше. Очень интересно, в чем может быть причина и допустимы ли данные значения? Особенно критичен пункт 1.1, т.к. существует вероятность, что в процессе соединения, будут возникать подвисания при работе пользователей.
Был бы очень благодарен Вашему комментарию.
Версия платформы: 8.3.16.1224 (x64)
Подключение происходит в рамках одной машины и единого сервера 1С.
В качестве теста использовались следующие конфигурации: Комплексная автоматизация 2.4 (далее КА) и чистая конфигурация с пустой базой (далее ЧБ).
На строчке кода:
V8COM.Connect(СтрокаСоединения);Серверная машина:
1.1 Подключения: КА1 (серверная) / ЧБ (файловая) -> КА2 (серверная) - 18-20 сек
1.2 Подключения: КА1 (серверная) / ЧБ (файловая) -> ЧБ (серверная) - 7 сек
1.3 Подключения: КА1 (серверная) / ЧБ (файловая) -> КА3 (файловая) - 9 сек
1.4 Подключения: КА1 (серверная) / ЧБ (файловая) -> ЧБ2 (файловая) - 5 сек
Развернул файловые базы на стационарной машине. Результат:
2.1 Подключение: ЧБ (файловая) -> ЧБ2 (файловая) - 1 сек
2.2 Подключение: ЧБ (файловая) -> КА (файловая) - 4 сек
1. Не могу понять, с чем может быть связана такая разница в пунктах 1.4 и 2.1, если серверная машина мощнее стационарной в разы?
2. Из анализа получения внешних соединений на серверной машине задержка всегда больше. Очень интересно, в чем может быть причина и допустимы ли данные значения? Особенно критичен пункт 1.1, т.к. существует вероятность, что в процессе соединения, будут возникать подвисания при работе пользователей.
Был бы очень благодарен Вашему комментарию.
(7) Долго искал решение и нашел: с 3х минут время сократилось до 15 секунд:
1) база должна быть в списке баз на компьютере с которого идет подключение, и в нее надо хотя бы 1 раз войти
2) если база - инициатор клиент-серверная, то надо или выполнять подключение "НаКлиенте" или реально войти на сервер под пользователем, под которым запущена служба и отрыть требуемую базу, тем самым выполнив кэширование "НаСервере"
1) база должна быть в списке баз на компьютере с которого идет подключение, и в нее надо хотя бы 1 раз войти
2) если база - инициатор клиент-серверная, то надо или выполнять подключение "НаКлиенте" или реально войти на сервер под пользователем, под которым запущена служба и отрыть требуемую базу, тем самым выполнив кэширование "НаСервере"
(8) можно поподробней про добавление в список баз?
имею:
1й сервер - кластер с базой 8.3
2й сервер - кластер с базой 8.2
соединение идет с 1го сервера ко 2му (из базыы 8.3 в базу 8.2), тупит.
пользователи работают на сервере терминалов (3й сервер)
пользователю, работающему в 8.3 и инициирующему соединение, в сервере терминалов в список баз добавляю базу 8.2. захожу и оставляю открытой, закрываю - не помогает ни так ни так, как только запускаю обмен из 8.3 - тупит.
захожу на 1й сервер под админом (под ним же запущен агент 1с 8.3, а так же агент 8.2 на втором сервере), добавляю в список баз базу 8.2, захожу в нее, оставляю открытой, при этом все тот же пользователь с третьего сервера инициирует обмен - тупит.
PS пользователь прописан в базах 8.3 и 8.2 одинаково, но обмен инициируется с указанием в модуле служебной учетки 1с, которая конечно прописана в базе 8.2
имею:
1й сервер - кластер с базой 8.3
2й сервер - кластер с базой 8.2
соединение идет с 1го сервера ко 2му (из базыы 8.3 в базу 8.2), тупит.
пользователи работают на сервере терминалов (3й сервер)
пользователю, работающему в 8.3 и инициирующему соединение, в сервере терминалов в список баз добавляю базу 8.2. захожу и оставляю открытой, закрываю - не помогает ни так ни так, как только запускаю обмен из 8.3 - тупит.
захожу на 1й сервер под админом (под ним же запущен агент 1с 8.3, а так же агент 8.2 на втором сервере), добавляю в список баз базу 8.2, захожу в нее, оставляю открытой, при этом все тот же пользователь с третьего сервера инициирует обмен - тупит.
PS пользователь прописан в базах 8.3 и 8.2 одинаково, но обмен инициируется с указанием в модуле служебной учетки 1с, которая конечно прописана в базе 8.2
(9) у меня все на одном сервере, на одной платформе, поэтому не уверен что могу подсказать корректно.
что вы вкладываете в слово "тупит"? долго идет подключение, или как у автора топика блокируется работа всех остальных?
1 почистьте весь кэш в appdata у пользователя сервера 3, админа в 1 и 2 сервере, посмотрите после этого в каком месте под каким пользователем кэшируется.
2 по опыту соединение или его кэш живет некоторое время,предположительно до закрытия основной базы из которой запускается соединение, т.е. повторное соединение проходит быстро. у вас как?
3 . сделайте пустую базу с пустой или минимальной конфигурацией, возможно большой модуль внешнего соединения в базе 8.2.
4. попробуйте базу 2 сервера запустить на платформе 8.3
5 попробуйте еще адрес базы указать файлом общих баз *.v8i у всех профилей.
6. перенесите соединение из сервера на клиент
7. опубликуйте базу на веб-сервере, попробуйте соединение по веб-ссылке
8. попробуйте windows- аутентификацию
9. через журнал регистрации попробуйте определить, что происходит дольше: до аутентификации,сама аутентификация или прогон по модулю внешнего соединения
что вы вкладываете в слово "тупит"? долго идет подключение, или как у автора топика блокируется работа всех остальных?
1 почистьте весь кэш в appdata у пользователя сервера 3, админа в 1 и 2 сервере, посмотрите после этого в каком месте под каким пользователем кэшируется.
2 по опыту соединение или его кэш живет некоторое время,предположительно до закрытия основной базы из которой запускается соединение, т.е. повторное соединение проходит быстро. у вас как?
3 . сделайте пустую базу с пустой или минимальной конфигурацией, возможно большой модуль внешнего соединения в базе 8.2.
4. попробуйте базу 2 сервера запустить на платформе 8.3
5 попробуйте еще адрес базы указать файлом общих баз *.v8i у всех профилей.
6. перенесите соединение из сервера на клиент
7. опубликуйте базу на веб-сервере, попробуйте соединение по веб-ссылке
8. попробуйте windows- аутентификацию
9. через журнал регистрации попробуйте определить, что происходит дольше: до аутентификации,сама аутентификация или прогон по модулю внешнего соединения
тупит сам импорт и блокируется работа всех остальных пользователей, т.е. тупит у всех.
собственно речь идет именно о тех же базах, что у автора, просто базы переехали на другой сервер. это та же компания, та же обработка. 1 соединение на процесс не спасает остальных - начинают тупить групповые обработки документов. в прошлый раз решилось добавлением базы в список пользователю, который запускает импорт, сейчас не сработало. копаю в этом направлении.
на первом сервере с кластером 8.3 поднял кластер 8.2, в нем создал базу, к которой идет подключение (получается к одной sql базе создано подключение с двух кластеров - разных физических машин. но т.к. требуется только импортировать документы из базы 8.2 в базу 8.3, думаю ничего критичного не произойдет, изменения идут только с одного кластера). идея была проверить, поможет ли если оба кластера будут на одной физической машине. не помогло, так же тупит. единственно - не почистил кеш сервера 8.3, смогу проверить только вечером.
собственно речь идет именно о тех же базах, что у автора, просто базы переехали на другой сервер. это та же компания, та же обработка. 1 соединение на процесс не спасает остальных - начинают тупить групповые обработки документов. в прошлый раз решилось добавлением базы в список пользователю, который запускает импорт, сейчас не сработало. копаю в этом направлении.
на первом сервере с кластером 8.3 поднял кластер 8.2, в нем создал базу, к которой идет подключение (получается к одной sql базе создано подключение с двух кластеров - разных физических машин. но т.к. требуется только импортировать документы из базы 8.2 в базу 8.3, думаю ничего критичного не произойдет, изменения идут только с одного кластера). идея была проверить, поможет ли если оба кластера будут на одной физической машине. не помогло, так же тупит. единственно - не почистил кеш сервера 8.3, смогу проверить только вечером.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот