Построение высокопроизводительного файлового сервера (между 2 компьютерами gigabit lan crossover)
Модераторы: SLEDopit, Модераторы разделов
-
rPman
- Сообщения: 22
- ОС: Ubuntu
Построение высокопроизводительного файлового сервера
Компьютеры подсоединены напрямую (витая пара) через гигабитные сетевые карты встроенные в материнку (обе nvidia nForce):
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
nVIDIA MCP67/68 - LAN Controller (PHY: Realtek RTL8211/8212)
Наблюдается заметное понижение быстродействия программ, работающих вместо диска с сетевой шарой, причем от 30% до 'в разы'.
С пол года назад практиковал бездисковую станцию linux по nfs (на глазок ощутимая потеря производительности, добавляется лаг при работе с меню kde/gnome).
С клиентом windows делал больше тестов, поднимал на сервере samba, ставил на клиенте windows for unix 3.5 и поднимал nfs шары (почти никакой разницы в производительности, по шустрее линейное копирование), сейчас стоит iSCSI а на сервере LVM (2 stripe блок 64кб) - все равно к примеру игры запускается раза в 4-5 медленней, хотя линейное чтение доходит до 100мбайта/сек.
Т.е. потеря производительности именно при операциях нелинейного чтения, тесты в популярных бенчмарках не проводил, но и так ясно, на что они покажут - задержки на любые операции.
Что служит виной подобного лага? подключение комп-комп (слышал что для дешевых гигабиток какие то проблемы должны быть)? Вообще это нереально на гигабитной сетке сделать высокопроизводительное удаленное хранилище, может я не то сетевое ПО выбрал или протокол IP(вариант с монопольным использованием канала рассматриваем но нежелателен), хотя что в данном случае лучше iSCSI? Может что то можно на linux (gentoo) подкрутить, настройки samba, nfs, ietd, ядра? а может вина и в windows? может так же настройки какие можно найти?
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
nVIDIA MCP67/68 - LAN Controller (PHY: Realtek RTL8211/8212)
Наблюдается заметное понижение быстродействия программ, работающих вместо диска с сетевой шарой, причем от 30% до 'в разы'.
С пол года назад практиковал бездисковую станцию linux по nfs (на глазок ощутимая потеря производительности, добавляется лаг при работе с меню kde/gnome).
С клиентом windows делал больше тестов, поднимал на сервере samba, ставил на клиенте windows for unix 3.5 и поднимал nfs шары (почти никакой разницы в производительности, по шустрее линейное копирование), сейчас стоит iSCSI а на сервере LVM (2 stripe блок 64кб) - все равно к примеру игры запускается раза в 4-5 медленней, хотя линейное чтение доходит до 100мбайта/сек.
Т.е. потеря производительности именно при операциях нелинейного чтения, тесты в популярных бенчмарках не проводил, но и так ясно, на что они покажут - задержки на любые операции.
Что служит виной подобного лага? подключение комп-комп (слышал что для дешевых гигабиток какие то проблемы должны быть)? Вообще это нереально на гигабитной сетке сделать высокопроизводительное удаленное хранилище, может я не то сетевое ПО выбрал или протокол IP(вариант с монопольным использованием канала рассматриваем но нежелателен), хотя что в данном случае лучше iSCSI? Может что то можно на linux (gentoo) подкрутить, настройки samba, nfs, ietd, ядра? а может вина и в windows? может так же настройки какие можно найти?
-
кодировщик
- Сообщения: 974
- Статус: зарёган в пятницу 13
- ОС: Linux
-
danger08
- Сообщения: 715
- ОС: Linux (CentOS, Ubuntu)
Re: Построение высокопроизводительного файлового сервера
rPman писал(а): ↑02.02.2009 11:17Компьютеры подсоединены напрямую (витая пара) через гигабитные сетевые карты встроенные в материнку (обе nvidia nForce):
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
nVIDIA MCP67/68 - LAN Controller (PHY: Realtek RTL8211/8212)
У меня проблема была с этими картами в CentOS 5.2, при использовании драйвера r8169 (у людей на Убунте было то же самое).
Заменил альтернативным драйвером r1000 (v1.05) и все встало и работает на ура.
Блогосайт - http://www.fateyev.com
-
rm_
- Сообщения: 3340
- Статус: It's the GNU Age
- ОС: Debian
Re: Построение высокопроизводительного файлового сервера
при использовании драйвера r8169 (у людей на Убунте было то же самое).
Заменил альтернативным драйвером r1000 (v1.05)
Надо пользоваться стандартным драйвером, тем более что для этой карты он давно входит в состав ядра.
Если с ним что-то не работает, репортить баги.
Т.е. потеря производительности именно при операциях нелинейного чтения
Вопрос ("а должно ли быть быстрее") сложный, но полученные результаты в общем-то логике не противоречат...
Просто посчитайте, какая огромная разница в количестве промежуточных программных и аппаратных "слоёв" между прямым доступом к локальному диску, и доступом к диску на другом компьютере.
Посмотрите где-нибудь в настройках, осуществляет ли клиентская операционка кэширование чтения/записи на iSCSI (не отключено ли это).
Включены ли Jumbo-фреймы для соединения. Равен ли их макс. размер, заданный на обоих компьютерах. Последний момент особенно критичен, т.к. Реалтек больше 7200 не умеет, а nForce может и до 9000 (если не "обрезок").
-
danger08
- Сообщения: 715
- ОС: Linux (CentOS, Ubuntu)
Re: Построение высокопроизводительного файлового сервера
Баги давно отрепорчены, только народ каждый день сталкивается с такой ситуацией. В будущем, может, что-то изменится, но врядли кого-то заинтересуют эти мега-интегрированные-девайсы, серьезные люди с ними не работают. Сам драйвер r8169 очень хорош для большинства моделей Realtek, только вот со встроенными сетевухами не особенно дружит - это проблема производителей железа с интегрированными сетевухами.
У меня при использовании r8169 были резкие падения пропускной способности при интенсивном сетевом обмене на довольно нагруженном хосте (файлопомойка), Сейчас стоит r1000 и никаких нареканий. Пусть человек попробует r1000, если это решит его проблему - больше ничего не надо.
Заголовок стоит "построение высокопроизводительного файлового сервера", встроенные гигабитки для этого не лучшее решение. Возьмите, например, нормальные карточки Intel, или Realtek на худой конец (только не встроенный
Блогосайт - http://www.fateyev.com
-
rm_
- Сообщения: 3340
- Статус: It's the GNU Age
- ОС: Debian
Re: Построение высокопроизводительного файлового сервера
врядли кого-то заинтересуют эти мега-интегрированные-девайсы, серьезные люди с ними не работают
Они встроены на подавляющем большинстве современных по крайней мере AMD-шных материнок, так что заинтересуют, можно не сомневаться.
Пусть человек попробует r1000, если это решит его проблему - больше ничего не надо.
Как ничего не надо, ещё как надо:
- навсегда отказаться от возможности ставить готовые Убунтовские ядра
- самому сидеть и прикручивать драйвер к ядру, после чего компилить оное из исходников
- иметь эту мороку каждый раз при желании проапгрейдить ядро до свежего релиза.
Это всё очень неудобно. Поэтому правильнее - добиться, чтобы работало "из коробки".
Возьмите, например, нормальные карточки .... только не встроенный
И только не PCI.
Встроенные сетевухи сидят на PCI-E, а у nVidia вообще, на своей особой шине, так что на PCI-картах их обойти не выйдет.
или Realtek на худой конец
Если невстроенный реалтек чем-то лучше встроенного, то это баг, и его надо исправлять.
Чип по сути один и тот же, кардинальных различий никаких быть не должно.
-
danger08
- Сообщения: 715
- ОС: Linux (CentOS, Ubuntu)
Re: Построение высокопроизводительного файлового сервера
rm_ писал(а): ↑02.02.2009 15:25Пусть человек попробует r1000, если это решит его проблему - больше ничего не надо.
Как ничего не надо, ещё как надо:
- навсегда отказаться от возможности ставить готовые Убунтовские ядра
- самому сидеть и прикручивать драйвер к ядру, после чего компилить оное из исходников
- иметь эту мороку каждый раз при желании проапгрейдить ядро до свежего релиза.
Это всё очень неудобно. Поэтому правильнее - добиться, чтобы работало "из коробки".
Проблема с таким девайсами у драйверов "из коробки".. А дел там реально на 5-10 минут:
- установить исходники ядра (чтоб хедеры зацепились при сборке драйвера);
- качнуть r1000_v1.05.tar.bz2 с сайта реалтек, это последняя версия, собирающаяся беспроблемно под последними ядрами;
- собрать модуль по инструкции внутри;
- внести изменения в modprobe.conf, загрузить через modprobe или перезагрузиться.
Если система ставит r8169 обратно, заблэклистить этот модуль.
Пересборки ядра и прочих страшных вещей не требует, даже для ярых бинарных дистрибутивов
Если невстроенный реалтек чем-то лучше встроенного, то это баг, и его надо исправлять.
Чип по сути один и тот же, кардинальных различий никаких быть не должно.
Давно разговоры об этом идут, со временем должны пофиксить. В общем, не переключайтесь (stay tuned
Блогосайт - http://www.fateyev.com
-
skor
- Сообщения: 419
- ОС: RTFM-OS v127.0.0.1
Re: Построение высокопроизводительного файлового сервера
[offtopic]ИМХО слова "высокопроизводительный" и "realtek" рядом не очень хорошо смотрятся.
Есть деньги на всякие SCSI, а на сетевую от Intel`а пожалели[offtopic]
Есть деньги на всякие SCSI, а на сетевую от Intel`а пожалели[offtopic]
-
rm_
- Сообщения: 3340
- Статус: It's the GNU Age
- ОС: Debian
Re: Построение высокопроизводительного файлового сервера
Спасибо, повеселили, советую почитать, что такое iSCSI.
Про реалтек зерно истины есть, но в отличие от стомегабиток 8139, гигабитные чипы 8169 (и их встраиваемые аналоги) больше не "худшие сетевые чипы планеты", и обладают вполне внушительным набором функций по разгрузке ЦПУ. Другой вопрос, насколько хорошо это реализовано, в том числе и в драйверах.
-
rPman
- Сообщения: 22
- ОС: Ubuntu
Re: Построение высокопроизводительного файлового сервера
Технические тесты Roadkil's disk speed 2.0: hdd 500гб (wd)/100гб iscsi lvm stripe на 2-ух 320Гб - access time 12.81ms/11.09ms, linear read 52мб-89мб/45мб-73мб, random read для 64к блоков 4.79мб/2.73мб, overal score 787.9/580.7. Игра Mirror's Adge (загрузка любого этапа сразу после запуска) с локального диска 2 'избиения полицейского'
mtu менял от 1500 до 7200 (кстати, как это они могут быть разными на обоих концах? подключение кросовер, и как его менять под windows?Т.е. потеря производительности именно при операциях нелинейного чтения
Вопрос ("а должно ли быть быстрее") сложный, но полученные результаты в общем-то логике не противоречат...
Просто посчитайте, какая огромная разница в количестве промежуточных программных и аппаратных "слоёв" между прямым доступом к локальному диску, и доступом к диску на другом компьютере.
Посмотрите где-нибудь в настройках, осуществляет ли клиентская операционка кэширование чтения/записи на iSCSI (не отключено ли это).
Включены ли Jumbo-фреймы для соединения. Равен ли их макс. размер, заданный на обоих компьютерах. Последний момент особенно критичен, т.к. Реалтек больше 7200 не умеет, а nForce может и до 9000 (если не "обрезок").
Про уменьшение прослоек - ну нужно будет попробовать AoE (но если он может только все устройство целиком - мне не подходит, а если любое блочное устройство - то не уменьшит количество прослоек, да и поддерживается ли win.. хз)
Я конечно понимаю хотеть не вредно, но мало ли, хотелось и бездисковую (бесшумную) станцию и без серъезных потерь производительности и денежных
Задействованы модули 8139too и 8139cp (в комп вставлена еще 100-мбит сетевуха RTL-8139/8139C/8139C+ (rev 10)), какой модуль к какой сетевухе сейчас посмотреть не могу, серер работает давно и dmesg уже не показывает сообщения в с начала загрузки, а перегружать его пока не хочу.
-
Ленивая Бестолочь
- Бывший модератор
- Сообщения: 2760
- ОС: Debian; gentoo
Re: Построение высокопроизводительного файлового сервера
какой модуль к какой сетевухе сейчас посмотреть не могу
посмотреть какой модуль к чему:
Код: Выделить всё
ls -l /sys/bus/pci/devices/*/driverСолнце садилось в море, а люди с неоконченным высшим образованием выбегали оттуда, думая, что море закипит.
-
danger08
- Сообщения: 715
- ОС: Linux (CentOS, Ubuntu)
Re: Построение высокопроизводительного файлового сервера
rPman писал(а): ↑04.02.2009 10:37Задействованы модули 8139too и 8139cp (в комп вставлена еще 100-мбит сетевуха RTL-8139/8139C/8139C+ (rev 10)), какой модуль к какой сетевухе сейчас посмотреть не могу, серер работает давно и dmesg уже не показывает сообщения в с начала загрузки, а перегружать его пока не хочу.
8139too и 8139cp - это ваше 100мбитное хозяйство (Realtek 8139). Они не используются для гигабиток.
Насчет dmesg - смотрите /var/log/dmesg, насчет модуля - можно посмотреть в /sys/bus/pci/devices/ или через lshal (параметр info.linux.driver для устройства)
Блогосайт - http://www.fateyev.com
-
rm_
- Сообщения: 3340
- Статус: It's the GNU Age
- ОС: Debian
Re: Построение высокопроизводительного файлового сервера
Технические тесты Roadkil's disk speed 2.0: hdd 500гб (wd)/100гб iscsi lvm stripe на 2-ух 320Гб - access time 12.81ms/11.09ms, linear read 52мб-89мб/45мб-73мб, random read для 64к блоков 4.79мб/2.73мб
Так это ещё достаточно неплохо.
Попробуйте random read блоками по 4к, сдаётся мне, что вот там-то и будет основная разница.
mtu менял от 1500 до 7200 (кстати, как это они могут быть разными на обоих концах
Запросто могут быть разными, при этом пакеты большего размера на компьютере с меньшим размером MTU будут либо обрезаться, либо вообще не доходить, увеличивая счётчик "dropped" пакетов.
подключение кросовер
Это вообще ни при чём - в отличии от скорости и дуплекса, MTU не согласовывается на уровне подключения.
и как его менять под windows?
В свойствах сетевого подключения, в настройках TCP/IP.
Там обычно даётся всего три или четыре варианта: 1500, максимум, и одна-две ступени между ними.
Я конечно понимаю хотеть не вредно, но мало ли, хотелось и бездисковую (бесшумную) станцию и без серъезных потерь производительности
Это очень хорошее и правильное желание, но лично я не уверен, возможно ли вообще добиться скорости загрузки игр из сети, сравнимой с локальной. В моих тестах разница в скорости тоже была. Но я не так много с этим экспериментировал (например, не пробовал iSCSI).
Поэтому мне кажется стоит рассмотреть вариант установки локально жёсткого диска (для игр).
Обратите внимание на диски WD серии GreenPower (5400 оборотов), они должны быть очень тихими.
К тому же у меня были надежды использовать выделенное хранилище на linux (со всеми плюшками) для windows серверов (на которых плюшками и не пахнет)
Смотря что хранить на таком хранилище. Для многих применений, вполне разумным вариантом видится Samba. Добавочная плюшка с нею - возможность использования настоящей производительной и надёжной юниксовой ФС (XFS, JFS, или скоро btrfs), в то время как поверх iSCSI без вариантов пришлось бы городить NTFS.
какой модуль к какой сетевухе сейчас посмотреть не могу
lspci -k
-
rPman
- Сообщения: 22
- ОС: Ubuntu
Re: Построение высокопроизводительного файлового сервера
диск 0 - локальный диск 1 - iscsi, какраз с меньшими блоками разницы нет... вообще то lv по умолчанию блоки 64к делает, но я делал 8кб, было только хуже (и readahead отключал), вернул все на по умолчанию.rm_ писал(а): ↑04.02.2009 12:31Так это ещё достаточно неплохо.Технические тесты Roadkil's disk speed 2.0: hdd 500гб (wd)/100гб iscsi lvm stripe на 2-ух 320Гб - access time 12.81ms/11.09ms, linear read 52мб-89мб/45мб-73мб, random read для 64к блоков 4.79мб/2.73мб
Попробуйте random read блоками по 4к, сдаётся мне, что вот там-то и будет основная разница.
ifconfig пишет все дропы, ерроры и т.д. по нулям. А ведь я и на 100мбтке ставил mtu 90.
я конечно понимаю что оффтопик, но не вижу, хоть убей. И не видел ни на серверных ни на десктопных виндах этого. в настройках тсп есть только ипишники, днс, винс и параметры фильтрации.
P.S. А если у меня бридж на винде? Просто mtu это же не уровень tcp это ниже?..
В винде без диска вообще никак, если загрузку по iscsi настроить можно, то своп по сети она не умеет. Сейчас у меня так и есть локально диск стоит для винды, игры либо в сеть либо локально устанавливаю, по ситуации, например в условиях 1г оперативки (отдельная песня, пока не куплю 2 планки по гигу, еще гиг будут валяться на полке) Crysis запускается на порядок шустрее по сети, а с локального диска уходит в непрерывный своп.rm_ писал(а): ↑04.02.2009 12:31Это очень хорошее и правильное желание, но лично я не уверен, возможно ли вообще добиться скорости загрузки игр из сети, сравнимой с локальной. В моих тестах разница в скорости тоже была. Но я не так много с этим экспериментировал (например, не пробовал iSCSI).Я конечно понимаю хотеть не вредно, но мало ли, хотелось и бездисковую (бесшумную) станцию и без серъезных потерь производительности
Поэтому мне кажется стоит рассмотреть вариант установки локально жёсткого диска (для игр).
Обратите внимание на диски WD серии GreenPower (5400 оборотов), они должны быть очень тихими.
На глазок оценил, что на чтение iscsi быстрее samba/nfs исключительно из-за того, что метаинформация фс кешируется локально, но на запись медленней, потому что число запросов повыше. Еще не пробовал ставить драйвер какой-нибудь linux fs под windows
Смешно, но модуля r8169 у меня нет
У вас нет необходимых прав для просмотра вложений в этом сообщении.
-
rm_
- Сообщения: 3340
- Статус: It's the GNU Age
- ОС: Debian
Re: Построение высокопроизводительного файлового сервера
диск 0 - локальный диск 1 - iscsi, какраз с меньшими блоками разницы нет... вообще то lv по умолчанию блоки 64к делает, но я делал 8кб, было только хуже (и readahead отключал), вернул все на по умолчанию.
Я говорил не о том, чтоб делать RAID с маленькими блоками, а о запуске теста случайного чтения, задав ему в качестве параметра этот размер блока.
А ведь я на 100мбтке ставил mtu 90.
Сколько-сколько?)
И не видел ни на серверных ни на десктопных виндах этого. в настройках тсп есть только ипишники, днс, винс и параметры фильтрации.
Да, я перепутал, не в настройках TCP/IP, а в свойствах самой сетевой карты. Если нету - значит MTU выше 1500 не поддерживается. В случае с nForce'ами так оно и есть на удешевлённых версиях чипсетов, на Вашем - кажется должно.
В винде без диска вообще никак, если загрузку по iscsi настроить можно, то своп по сети она не умеет.
8 гигабайт ОЗУ, и без свопа.
-
danger08
- Сообщения: 715
- ОС: Linux (CentOS, Ubuntu)
Re: Построение высокопроизводительного файлового сервера
Но это не мешает собрать сторонний модуль, и назначить его для устройства (если есть в этом необходимость).
Блогосайт - http://www.fateyev.com