proNovell

Сервер по прошествии 3х дней с перезагрузки начинает терять пакеты. Симптомы следующие: копирование файлов становится раз в 10 медленнее, файлы долго открываются, задержки при чтении произвольного участка файла. На гигабитных портах скорость копирования примерно половина 100 мегабитной, на 100 мегабитных - как на 10. Подобный характер тормозов проявлялся когда использовался свич 3com 4226T (параметр hol, поменял 18 на 50 - стало нормально)

Грешу на интеловское железо, а именно на эзернетки. там гигабитную скорость нельзя выставить принудительно, только автоопределением. Драйвера новейшие с сайта. POLLING MODE.

Может кто уже это проходил? Любые идеи, я уже больше месяца вот так подвешен. Работать невозможно.

(NW 6.0 Sp5, все патчи, Intel 7501VW2, Adaptec 2120, 2 гига памяти, 6 винтов в корзине, гигабитный свич (циско), дофига клиентов)

...свич 3com 4226T...

Хм... если я не перепутал, то некогда кто-то из коллег перешивал прошивку такой машинки. Симптомы были похожи: медленная работа, потеря пакетов....

Перешил уже, настроил qos - часть пакетов перестала теряться
Теперь их теряет только сервер, и то по прошествии двух-трех дней.

NSS работает нормально, проверял прогружая IPX. Вот по IPX не тормозит, проблемы только с IP. Тонкими настройками рулил - никакого эффекта вообще (Nagle, SACK, Large Window...)

Может быть включить LACP и соединить сервер со свичом обоими портами? А может быть в драйвере утечка памяти и она вся за 3 дня утекает? Чем можно посмотреть механизм потери пакетов? Есть какое-то средство? Я готов почти на все - больше месяца перед начальством руки ломаю.[/img][/i]

утечка памяти и она вся за 3 дня утекает?

Утечку хорошо смотреть триальным Адремом- в клиент-серверной редакцииа - ставите, выбираете модуль, который надо попасти и смотрите сутки - другие...

Ох уж эти 3COM 4226T, (cencored)... Сам намучался с ними порядком... Да что говорить, читайте сами, вот цитата:

Прежде чем переходить к рассмотрению результатов тестирования коммутаторов, отметим, что в таблице с результатами отсутствует коммутатор 3COM 3C17300 SuperStack 3 Switch 4226T. При этом далее по тексту приводится описание коммутатора 3COM 3C17300 SuperStack 3 Switch 4226T и в таблице можно найти его подробные технические характеристики. Дело в том, что коммутатор 3COM 3C17300 SuperStack 3 Switch 4226T оказался единственной моделью, которая не смогла справиться ни с одним тестом. Причем мы возьмем на себя смелость утверждать, что речь идет не о конкретной бракованной модели, а именно о линейке SuperStack 3 Switch 4226T, поскольку нам и ранее доводилось слышать от пользователей жалобы на некорректную работу этого коммутатора. В ходе тестирования мы лишь подтвердили наши опасения относительно этого коммутатора.

Остальное здесь: http://lib.csu.ru/dl/bases/prg/kompress/articles/2004_04_testCommutators/index.htm
(читайте сразу "Результаты тестирования")

Сегодня говорил с сертифицированным инженером 3сом, он поклялся, что не имел проблем с этими свичами, и про HOL Protection даже не знает. Зато подал идею: надо порулить размером пакета на уровне IP.
У меня этот размер больше 4К. По идее должно быть пофигу - свич второго уровня, но все-таки? У кого какие параметры выставлены?

Покажите это "иженеру" 3Сом.

SuperStack 3 Switch 4200 - Priority traffic 'fails' between ports on different ASIC's
Problem: Priority traffic 'fails' between ports on different ASIC's
Fact: SuperStack 3 Switch 4226T
Fact: SuperStack 3 Switch 4250T
Fact: 3C17300
Fact: 3C17302
Fact: ESD4537
Fact: 802.1p
Fact: Priority
Fact: Low priority traffic prioritisation between ports on different ASIC device
Problem: Priority traffic fails between ports on different ASIC's
Problem: Prioritization of low priority traffic between ports may not work as expected.
Cause: Prioritization of low priority traffic between ports may not work as expected.There are basically two scenarios, the one of which will work as expected and the other which will not.Consider three ports - ingressPort(A) and ingressPort(B), are both transmitting low priority data to egressPort(C). The expectation is that the ratio of traffic received on egressPort(C) from ingressPort(A) : ingressPort(B) is 50 : 50.Scenario 1:If all three ports, A, B &C are located on the same ASIC device (the ports numbers depend on whether a 24port or 48port switch is being used), the ratio of received traffic ingressPort(A) : ingressPort(B) is 50 : 50.Similarily, if each port A, B and C are each on different ASIC devices the ratio of received traffic will be 50 : 50.This is OK.Scenario 2:If one of the ingress ports, say ingressPort(A), and egressPort(C) are on the same ASIC device, whilst the other ingress port, ingressPort(B), is on another ASIC device, the ratio of traffic received from ingressPort(A) : ingressPort(B) will be approximately 40 : 60 (or even 30 : 70). This is not OK.
Cause: In the problem scenario 2, the ratio of low priority traffic destined for the egressPort(C) is biased towards traffic being sent from the port which is located on a different ASIC, i.e ingressPort(B). This is due to the different buffer thresholds set for the external 10/100 ports verses that for the internal G-LINK (the G-LINK provides the communication path between all the ASIC devices in the Switch). Consequently, during congestion, head of line (HOL) thresholds will kick-in before the G-LINK buffer thresholds - this results in more ingress traffic being dropped on ports that reside on the same ASIC as the egress port.
Fix: There is no current fix using the Galileo 483xx ASIC switch chipset.A possible get-around is to ensure that (in an isolated case) the ports are either all on the same ASIC or on different ASICs. If multiple groups of ports are involved, the balance of low priority traffic received from the transmitter ports is not deterministic and will rely entirely on the buffer levels an HOL at any point in time.

Похоже на мой случай: "тормозными" порты становятся непредсказуемо, когда попало. Обсервер не показывает дропнутых пакетов. Статистика соединения (на свичах и на сервере) не показывает битых фреймов. Пинг стабильный и короткий как надо. Похоже тормозить начинает только при серьезной загрузке свича. Например при копировании большого файла. Сервер воткнут в гигабитный (естественно) порт.

Почему-то не тормозит в первые 2 дня работы сервера. Погоняем, посмотрим...

Сегодня заменил свич - тоже 24+2 гигабитных, токо неуправляемый.
Как тормозило, так и тормозит! Это не свич, ЭТО СЕРВЕР! И не все соединения, а НЕКОТОРЫЕ. Остальные работают нормально. Проблема даже не в драйверах, ПРОБЛЕМА В НОВЕЛЕ! В реализаци стека протоколов. Все пропатчено...

ЧТО ЭТО МОЖЕТ БЫТЬ??? Буду рад любой идее!

Может сетевая карта на сервере?
в мониторе нет ошибок?

Jack The Ripper писал(а):Грешу на интеловское железо, а именно на эзернетки. там гигабитную скорость нельзя выставить принудительно, только автоопределением. Драйвера новейшие с сайта. POLLING MODE.

Может кто уже это проходил? Любые идеи, я уже больше месяца вот так подвешен. Работать невозможно.

(NW 6.0 Sp5, все патчи, Intel 7501VW2, Adaptec 2120, 2 гига памяти, 6 винтов в корзине, гигабитный свич (циско), дофига клиентов)

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

Орлов Алексей писал(а):Может сетевая карта на сервере?

Очень сильно сомневаюсь.

Переводил, менял свичи (3сом 3300ХМ. циска гигабитная). Не карточка это: тогда бы все тормозили, а тормозят некоторые соединения попеременно. Что-то на уровне IP или выше. Изучл доку по стеку, проверил все на предмет нехватки чего-либо. Все вроде в норме (\е, _IP, _TCP, inetcfg, tcpcon...). Может NCP? Авторизация соединений? Чем больше загрузка - тем быстрее начнет тормозить.