Тормоза при работе Netware 5.1

[Сергей Петухов]

Оплоки для TFS не нужны вообще, настраивать их в отсутствие на сервере NSS не вижу смысла. Там иные механизмы управления блокировкой. Закомментируйте все свои художества на сервере по части оплоков, восстановите на клиенте дефолтные настройки File Commit и Caching Mode. Если и тут все будет тормозить - разбирайтесь с сетевушкой.

Интересно. Там, где читал про настройку оплоков не упоминался этот нюанс.

Касаемо "8 Мб маловато" - Вы какой скорости ожидаете и по какому протоколу? Гигабит даже теоретически не в десять раз быстрее сотки, реальный прирост - около 20% (без Jumbo frame, поддержки которых в 5.1, скорее всего, нет).

Для начала Хотелось бы хотя бы 10-20мб/с. по ip
5.1 Юмбу вроде поддерживает, но это буду на следующем этапе пробовать, после того как сервер стабильно проработает хотя бы недельку-другую. http://www.novell.com/support/kb/doc.php?id=10084286

Касаемо солянки из IPX и IP - надо определяться с протоколами (опять согласен с Костей). Идеальный вариант: изолировать клиентов, сидящих на IPX, в отдельный сегмент и настроить работу сервера с этим сегментом. Вообще если этот сервер не нужен для чего-нить типа Border Manager, GroupWise и т.д. и в сети нет машин с W7, я бы рекомендовал отказаться от TCP/IP. IPX более эффективен. И на всякий пожарный посмотрите снифером долю широковещательных пакетов в сети.

Планируем отойти от IPX, потому, что в сети всё больше становится станций с windows 7 и всё меньше с windows 98. Опять-же Jumbo только на IP работает.
Снифером глянем.

[Сергей Петухов]

Да подсетей-то можете делать сколько вам нужно, тут замечание относилось к тому, что для IP это у вас разные подсети, а для IPX - одна и та же. Если это физически разные сегменты сети, то и для IPX-а должны бы использоваться разные номера подсетей, иначе это неверные настройки.

Физически один сегмент.

Дык, на сайте Novell же. download.novell.com/patch/finder/,

Нда. Видать по запарке не в Patches, а в Download ткнул, вот и не было там 5.1. Спасибо.

[Иван Левшин aka Ivan L.]

Все написанное за оплоки писалось во времена, когда уже практически забыли и за TFS, и за IPX (лично я до сих пор уверен, что надо было новелю не жадничать, а отдать IPX/SPX "в массы" - сдается мне, что вместо повсеместного TCP/IP сейчас был бы IPX/SPX. TCP/IP в принципе убогое убожество - на мой не самый просвещенный взгляд), потому Вы и не читали ничего подобного. В любом случае при работе с DBF на TFS древние NW3.x показывают скорость, ничуть не худшую в сравнении с NW5.x/6.x (конечно, с учетом скорости работы винтов), они 100% никаких Oplock не поддерживают (их сняли с поддержки задолго до изобретения этого костыля).

"Юмба" - это, надо понимать, Jumbo? Я бы не стал вот так прям надеяться - изначально технология была далеко не "торт", так что оно может быть заявлено, но фактически неработоспособно. Вообще говоря, я лично уверен, что чем проще городушка - тем надежнее, оттого настоятельно всегда и всем рекомендую не заниматься усложнением себе жизни. Jumbo никак Вас не спасет в случае кооперативного использования DBF - ну даст оно Вам еще 1-2 пользюков, это Вас спасет? Ущербен сам файл-серверный подход, а не транспорт между клиентом и сервером.

И еще: прошу прощения, если вопрос покажется глупым, но у вас оборудование-то Jumbo-фреймы нормально поддерживает? А то получится как с оплоками - настроили на сервере и ждем, когда заработает. Забыв при этом, что оплоки - игра обоюдная, настраивать надо и на сервере, и на клиенте.

[Константин Ошмян]

Не, вот только не надо пробовать там ещё и Jumbo-фреймы использовать!

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

В общем, не для общения сервера с клиентами это.

Кстати, мой пример:

Код: Выделить всё

Set maximum physical receive packet size = 18000

остался как раз со времён, когда я с этими Jumbo-фреймами экспериментировал. На практике, конечно, так много не надо (а вот сколько именно надо - я не помню, что-то в районе 4К было).

[Сергей Петухов]

Ясно. Jumbo frame - отложим в сторону.

[Павел Гарбар]

Тормозить могут сетевые платы на чипах Realtek 10/100. Они в произвольный момент перестают работать стабильно на 100 Мбит/с. Выглядеть это может как чтение 100Мбит, а запись 200 килобит - 1 мегабит (или наоборот, пишет быстро, а читает медленно). В таком режиме обращение к базе приводит к непредсказуемым результатам, а при копировании файлов - долго и рывками, с вероятностью недокачки длинного файла.
После того, как карта вдруг сваливается в такой режим она уже в нормальные 100Мбит не возвращается.
Jumbo-фреймы для запросов к базам данных маловероятны. Они хороши для копирования файлов больше нескольких мегабайт.
И да, IPX/SPX лучше

[Сергей Петухов]

Тормозить могут сетевые платы на чипах Realtek 10/100. Они в произвольный момент перестают работать стабильно на 100 Мбит/с. Выглядеть это может как чтение 100Мбит, а запись 200 килобит - 1 мегабит (или наоборот, пишет быстро, а читает медленно). В таком режиме обращение к базе приводит к непредсказуемым результатам, а при копировании файлов - долго и рывками, с вероятностью недокачки длинного файла.
После того, как карта вдруг сваливается в такой режим она уже в нормальные 100Мбит не возвращается.

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

в выходные и несколько последующих вечеров поплясал с бубном около сервера:
выбросил карточку dlink dge528t, вместо неё сейчас установлена гигабитная Marvell Yukon. Оставил IPX только на одной карточке, обновил ПО на Priocurve до PB.03.10 и перенёс сетевые настройки в INITSYS c помощью inetcfg
В результате скорость копирования с сервера чуть поднялась и теперь около 8мб/сек.


Сниффер wireshark особого криминала не выявил, хотя опыт его использования невелик, может что-то и недоглядел.

[Павел Гарбар]

Можешь проверить с помощью прямого провода из раб. станции в сервер скорость копирования? Чтобы исключить плохо обжатые(разболтавшиеся) коннекторы, провода, патч-панели, коммутаторы и прочее...
Я на прошлой неделе имел проблемы как раз с прямым проводом на серверах Win2012 Будучи воткнуты в коммутатор - работали, а на прямом проводе - ритмично теряли линк. Выяснилось, что дело было в родных драйверах от МС, поставил от Realtek'a и линк перестал падать.