![]() |
|
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 | Внезапно :) |
|
Список тем форума |