1С:Предприятие :: 1С:Предприятие 8 общая

Толстый клиент тормозит по сети при клиент-серверном подключении

Alex1

01.04.21 - 13:41

Добрый день.

Есть сервер с Windows Server 2016, MS SQL 2016 и сервером 1С 8.3.16.1876.
SQL База "Бухгалтерия для Украины, редакция 1.2".
Если запускать отчет в толстом клиенте (клиент-сервер) на этом же сервере - он отрабатывает 10 сек.
Если запускать отчет в толстом клиенте (клиент-сервер) на любом другом, даже значительно более мощном компе - он отрабатывает 50 сек.
Сеть - просто гигабитный коммутатор.
При запуске отчетов - CPU компов не нагружаются более 2-3%, диски и сеть тоже без нагрузки.
Не могу найти узкое место, которое бы объяснило такую разницу во времени выполнения отчетов (и других операций)
Подскажите пожалуйста, как можно найти такую причину ?
Возможно есть какие-то конфигурации специально для этих целей ?

Fragster

1 - 01.04.21 - 13:48

узкое место - синхронные сетевые вызовы, возвращающие малое количество данных. переходи на тонкий клиент целиком.

Alex1

2 - 01.04.21 - 13:53

Но разве в случае запуска толстого клиента на том же сервере - он не использует те же синхронные сетевые вызовы ?

Повелитель

3 - 01.04.21 - 14:14

(0) Замечал подобное, решения тоже не нашел. Но мне кажется проблема в сети, точнее в комутаторах.
У меня такая конфигурация.
На 1 этаже стоит свитч, сервер и терминальный сервер.
На 2 этаже стоит свитч и 10 компьютеров.
На 3 этаже стоит свитч и 10 компьютеров.

Сеть везде 1Гб и скорость вроде везде нормальная, ping 1mc

Но запускаю отчет на сервере или терминальном сервере, которые стоят на 1 этаже и воткнуты в 1 свитч, отчет строится быстрее гораздо, чем на 2 и 3 этаже.
Причину не знаю, грешу на сеть. Сами свитчи могут тормозить, хотя при простом тестировании, когда копируешь файл на 1 Гб, показывают себе хорошо.

Вам можно проверить скорость запуска отчета подключив этот компьютер к комутатору, который подключен к серверу. Думаю тоже будет 10 секунд отрабатывать.

Alex1

4 - 01.04.21 - 14:18

(3) Все подопытные включены в один свитч.
Все предыдущие опробованные компы с Windows 10 - отчет занимал 50 сек. Попробовал подключиться со старенького Windows Server 2003 - 10 сек !

Повелитель

5 - 01.04.21 - 14:21

(4) Кстати да, у меня сервер и терминальный сервер это Windows Server 2016 и Windows Server 2008r2.

А клиенты, это windows 7.

Возможно я зря грешу на сеть, а дело в ОС

Повелитель

6 - 01.04.21 - 14:30

Наткнули на мысль, если это касается Windows 7 и Windows 10.
Читал давно, что нужно настройки ОС и сетевого адаптера делать.
Вот нашёл одну из статей:
https://mega--obzor-ru.turbopages.org/mega-obzor.ru/s/kak-ispravit-medlennyj-internet-posle-obnovleniya-windows-10.html?utm_source=turbo_turbo

fisher

7 - 01.04.21 - 14:51

Ну, сетка очевидно. Может, дело в большом объеме данных, получаемом для отчета? Условно говоря, какой порядок количества строк результата?

fisher

8 - 01.04.21 - 14:54

(4) Хм. Интересно. Может, какая-то тонкая хрень типа размера пакетов.

Fragster

9 - 01.04.21 - 14:56

(2) использует, но условные 0.0001мс и 0.1мс - есть разница? а этих микровызовов мнооооого. особенно весело работать с хранилищем, или там сравнение объединение запускать, если пинг до него миллисекунд так 50

acht

10 - 01.04.21 - 14:57

(8) Или банальный не отключенный ipv6

fisher

11 - 01.04.21 - 15:01

(10) Все равно непонятно. Просадка в 5 раз на минуточку.

Alex1

12 - 01.04.21 - 15:12

(10) IPv6 отключен

Fragster

13 - 01.04.21 - 15:12

(11) значит из всего времени сетевое взаимодействие занимает 80%

Alex1

14 - 01.04.21 - 15:13

А нет ли профайлера для 1С ? Или конфигурации, которая помогает найти узкие места ?

Fragster

15 - 01.04.21 - 15:14

(14) в данном случае пможет переход на тонкого клиента

Alex1

16 - 01.04.21 - 15:15

Очень похоже на накладные расходы на сетевое взаимодействие с Win10.
Нужно понять, почему старые операционки типа 2003 не тормозят.

Alex1

17 - 01.04.21 - 15:16

(15) Если не разберусь - придется так и поступить

arsik

18 - 01.04.21 - 15:21

(12) Значит не до конца. Просто снять галку ipv6 в сетевых подключениях - недостаточно. Гугли.

arsik

19 - 01.04.21 - 15:22

А еще может оказаться, что сервер и не железный совсем, а там свои заморочки.

Fragster

20 - 01.04.21 - 15:25

(16 тормзят)

acht

21 - 01.04.21 - 15:28

(11) Ну или протоколы на MSSQL не настроены. На сервере внезапно включается шаред мемори, клиенты пытаются по именованым каналам, а древний 2003 которого послали с каналами, переключается на тсипип =)

fisher

22 - 01.04.21 - 15:43

(13) Раз есть компы что не тормозят - значит дело не в харде. И возникает вопрос, что такого может быть не так настроено на хосте, что в 5 раз просаживает сетку на одинэсном профиле нагрузки.

Alex1

23 - 01.04.21 - 15:50

(21) Простите, не совсем вас понял.
К MSSQL подключается только СерверПриложений1С, расположенный на том же железе.
И соединение у них "Shared memory".
А толстые клиенты подключаются с Win10 и Win2003.

Fragster

24 - 01.04.21 - 16:10

(22) может и в харде. например через коммутатор плохо лезут джумбо фрэймз или как там большие пакеты называются. а 2003 в это не умеет, получается обычные пакеты, у которых rtt в 2-4 раза меньше из-за коммутатора

Fragster

25 - 01.04.21 - 16:11

нужен точный пинг, чтобы проверить, стандартный виндовский с точностью 1мс недостаточный.

fisher

26 - 01.04.21 - 16:24

(24) Ок. Может и в харде, но все равно должна быть разница в работе хостов. Понять бы её - а дальше дело техники.
Может, анализатор пакетов какой-нить может помочь...

Fragster

27 - 01.04.21 - 17:21

во эта умеет до тысячных мс смотреть: https://nmap.org/nping/

Fragster

28 - 01.04.21 - 17:23

хотя основная метрика для 1с - это скорее количество пакетов в секунду

Alex1

29 - 01.04.21 - 17:36

Нет, проблема не в физической сети.
Подключил Win7x64 - получил 10сек !
Добавил гроздь коммутаторов последовательно, и повесил на дальний из них этот Win7x64 - те же 10 сек !

Т.е. проблема проявляется только если в качестве клиентов выступают Win10.

Alex1

30 - 01.04.21 - 17:40

Что проверял:

 - отключал напрочь IPv6 (и "галочкой", и в реестре, и через netsh...)
 - отключал защитника/файрволл
 - JUMBO фреймы включены и бегают без проблем

Alex1

31 - 01.04.21 - 17:44

Причем толстый клиент, подключающийся с Win7x64 отрабатывает даже на пару секунд быстрее, чем локально запущенный на Win2016 (на котором MSSQL и Сервер1С).
Подключение во всех случаях разумеется через клиент-сервер.

Fragster

32 - 01.04.21 - 19:02

сейчас подключишь вин 10, а там тоже все будет быстро формироваться, вот мы все поржем

Alex1

33 - 01.04.21 - 19:31

(32) Если бы ))) c Win10 то все и началось.
Пробовал 5 разных машин - и AMD и Intel.
И свежие десятки, и LTSB/LTSC - одна и та же картина.

Alex1

34 - 01.04.21 - 19:38

Взял стандартный отчет "Главная книга" за 2019-2021гг

Профайл на Win7x64:
http://i.piccy.info/i9/2306883fb3c4a59e5324d98638fe60fe/1617294336/23523/1423478/12242win7x64.png

Профайл на Win10x64:
http://i.piccy.info/i9/104f9481149d21900ae0122b0b4d3efd/1617294472/28556/1423478/win10x64.png

Провинциальный 1сник

35 - 01.04.21 - 20:03

(30) Я бы джумбо вообще отключил. Не все коммутаторы умеют с ними работать. И как следствие - происходят задержки, пока протокол сообразит уменьшить размер пакета.

Провинциальный 1сник

36 - 01.04.21 - 20:14

(34) Ну тут же ясно видно. Тормоза на .ПроверитьПрисоединение() - это значит, что сеть скорее всего ни при чем. Скорее всего задержка из-за обращения к драйверу принтера для получения параметров страницы. Попробуйте на этом компе сделать принтером по умолчанию какой-нибудь из стандартных типа pdf или xps -принтеров.
Кроме того, есть нюанс в последних версиях платформы с 8.3.16: работа с принтером вынесена из dll в отдельный процесс. И запуск этого процесса занимает какое-то время, задержка возможно из-за антивируса - попробуйте каталог с 1с добавить в исключения антивируса.

fisher

37 - 02.04.21 - 09:46

Внезапно :)

Список тем форума

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.