Здравствуйте.
Имеется два сервера:
1. Роли: Терминальный сервер, Файловый.
2. Сервер 1с + SQL.
Связаны они гигабитным каналом через обычный неуправляемый свитч dlink (2 канала по 1гб +24 по 100мб).
В остальные порты воткнуты обычные 100мб свитчи из разных кабинетов + еще один типа связующий, из-за постоянных переездов.
Дак вот, если какой либо один пользователь из"кабинетов" начинает копировать себе большой файл из шары на первом сервере, то у остальных начинает дико тормозит 1с-ка. Как только копирование заканчивается - все летает.
Почему так происходит, ведь сервера связаны гигабитным каналом и скорости должно хватать? Объясните пожалуйста. Во вложении, набросал примерную схему сети.
Думаю, что виновен "связующий" свитч и его нужно убрать из сети вовсе, но может существует другое решение...

во первых я не уверен, что если стоит гигабитник - то они общаются именно по нему а не по длинному кольцу через 5 маршрутиризаторов.

вот как настроить http://wiki.mista.ru/doku.php?id=it:set_dual_net

во вторых нужно смотреть загрузку операционки (памяти) в момент копирования, по тому что если есть гигабитник то сервак делает большую очередь (из расчета что клиент будет то же гигабитник и скорость будет большая), а клиент работает медленно и файловый буфер отьедает всб память

Отключи на гигабитных сетевухах джумбо-фреймы. Они в сочетании с обычными размерами кадров часто глючат, при этом возникают множественные переповторы пакетов..

(0) а напрямую не вариант соединить ?порт в порт , нафиг свич?

Это простая физика.
Представь взаимосвязанную сеть водных каналов. Наплевать, что одни из них широкие и глубокие - все определяется самым "медленным" каналом. Установка любых "продвинутых" шлюзов ничего не решает.
Возможно, только при разделении сетей и их ассинхронности.

сколько он времени тратит на таблицу ? мл/сек а когда куча запросов

Благодарю всех за советы. Сейчас уже не на работе, завтра постараюсь успеть попробовать порт-в-порт и отпишусь.

(4) Коммутируемый эзернет такую ситуацию пережевывает нормально. Если клиент с соткой тянет файл с сервера с гигабитом - это не должно существенно сказываться на связь между серверами по гигабиту. "Дикое торможение" возникает по какой-то иной причине. Я бы начал с последовательного отключения фич на сетевых адаптерах.. начиная с джумбофреймов и кончая оффлоадингом.

(7) к него через свич идет , ессественно тормоза

(8) Это неестественно. Свич конечно при нормальной работе вносит некоторую задержку, но это проценты, а не разы, и ни в коей мере не может быть "диким торможением".

1с-ка ка запускается? На терминале или тонким клиентом на компах пользаков?

Скорей всего, тормоза начинаются в сети 100 мегабит из-за того, что файл забивает весь буфер в свитче - отправка с сервера пакетов происходит быстрее, чем они долетают до конечного компьютера, а так как там используется UDP, то буферизация и отслеживание выполняются уже на более высоком уровне.
(Самый прикол ещё в том, что при очень большом файле и маленькой скорости в конце будет точка обрыва связи, когда передача файла прекратится).
И, насколько я знаю, сей процесс не лечится - конечно, если костыли с уменьшением MTU и т.п. действиями, но суть проблемы оно не решает.

> сей процесс не лечится

лечится

http://mdata.yandex.net/i?path=b1004154253_img_id8866997714970453680.jpg

http://market.yandex.ru/model.xml?modelid=4995343&hid=91088
3.5 тыщи рублей

(11) "тормоза начинаются в сети 100 мегабит из-за того, что файл забивает весь буфер в свитче - отправка с сервера пакетов происходит быстрее, чем они долетают до конечного компьютера, а так как там используется UDP, то буферизация и отслеживание выполняются уже на более высоком уровне"
Забить буфер свича с гигабитными линками трафиком сотки в режиме копирования файла - нереально. И вообще буфер тут ни при чем.. свич можно зафлудить сплошным потоком мелких пакетов, но к копированию файлов это не относится вообще никак. Проблемы где-то в другом месте.

Может на терминальном сервере (он же файлсервер) банально работает антивирус, настроенный на проверку всех открываемых файлов? Или какой-нибудь прочий софт, очумелыми ручками установленный...

(13) Ну, проблему можно частично решить, просто поставив отдельный свитч между серверами, а в него уже воткнуть dlink.
Ну или (12), но там нужно разделить всё на подсети - тогда будут работать приоритеты трафика.

И, всё таки, есть подозрение, что тормозит просто терминал, так как канал забит.
P.S. у dlink, наверняка, хоть и порты 1Гб, то используются они для связи коммутаторов и никакого приоритета для общения между портами нет, а наоборот, предполагается максимальная отдача данных по портам подключения.
Ну и буфер один на всё - и отлуп получают все и равномерно при его переполнении.

(9) расскажи  всем

(11) только не в свиче а в компе....

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

далее следует отключить протоколы файлового сервера (включая нет биос) от гигабитного интерфейса (на нем оставить только тси айпи).

А вообще подобное очень часто бывает на новых серверах где пытаются развести зоопарк, советую файловый сервер вынести на физически другую машину...

(16) "для начала на карте которая подключена к 100 мб следует
отключить гигабитныую скорость а явно установить ее в 100мб. "

Вот зачем фантазировать? Разве ТС говорил о том, что на серверах по несколько сетевушек? Топология, исходя из стартового топика, вполне ясная - стоит комбиинированный свич гиг-сотка, в гигабитные порты включены сервера, в соточные включены кабинетные свичи. Топология вполне адекватная, ИМХО, и проблема не в нехватке пропускной способности сети, а в настройках на серверах..

(17) хм... видимо я отстал от железа... на досуге почитаю...

всегда считал что неуправляемые свичи работают на одной скорости, по этому подумал, что у автора 2 сетевухи одна на 100 другая на 1000.

Кстати а как такой свич в принцепе может рулить трафиком? я имею в виду переход из гигабитного канала в соточный? По логике он должен загрублять гигабитный канал или его буфиризировать. Если он его загрубляет - то сервер не знает о проблемме и думает что сетка гигабитная, тогда мое предположение спроведливо.

Если железо действительно такое - то автору нужно разделить по виланам трафик между сервер-сервер и сервер-пользователь, и явно прописать в настройках разные скорости подключения....

Попробовал отключать джамбофреймы и flowcontrol, никакой реакции. Порт в порт думаю на выходных попробую. На сервере нет никакого зоопарка из ненужных программ, что с антивирусом, что без него, всё одинакого.
Заметил ещё, что более всего начинает тормозить, при копировании из одного места. Может там дохлый свитч...
С остальных когда, чувствуется, что подтормаживает, но не более того.

(0) Учитывай ещё скорость записи-чтения на диске сервера
если скорость чтения на диске сервера 100мбайт в секунду, и кто-то начинает гнать себе по сетевому каналу, позволяющему такую же скорость на свой диск, то что остаётся остальным? А когда 10 человек начинают качать-заливать файлы? Какая скорость на диске становится?

+(20) в момент когда копируют по сети, попробуй на сервере, на диске сам какое-нибудь файло большое тоже скопировать из папки в папку, погляди на разичия скорость

(18) "Кстати а как такой свич в принцепе может рулить трафиком? я имею в виду переход из гигабитного канала в соточный?"

А зачем ему вообще рулить трафиком? Это может быть вообще тупой неуправляемый свич. Пакет поступил на порт, запомнился, проанализировался адрес получателя, если известный - послали на порт, на котором анонсирован адрес, если неизвестный - послали на все остальные порты.. Если скорость входящего потока (гигабит) на исходящий (сотка) превышает пропускную способность - на порту отправки выстраивается очередь, а новые пакеты тупо дропаются. Протокол TCP это отслеживает (по отсутствию подтверждений о приеме сегментов), и замедляет передачу, вводя задержку, повторно передавая нужные сегменты при необходимости.

802.3x Flow-Control или нет?