Линукс, самба, гигабит

[shuras]

Вот решил тут отпостить проблемку. Мож кто сталкивался.

Текущая ситуация. Имеется фильмовый и софтовый сервак и клиентов эдак под 500. Дисковая подсистема тянет неплохо. Сетка 100 мегабит, а в центре гигабит и на нем серваки.

Когда то 100 Мегабит было кругом и было всем счастье. Кто-то неторопливо смотрит фильмы а кто-то качает. При этом качающие забивали интерфейс до 100 процентов и качали себе в меру попавшей на них полосы. Клиентов прибавилась и 100 мегабит уже не хватает. Поставили еще 100 Мегабит, повесили балансинг по интерфейсам на исходящие пакеты. Все работает чудно. Если неактивные пользователи забивают мегабит 70 исходящих, то активный пользователь если он один легко выбирает свои 9 Мегабайт в секунду.

Все вообщем было чудно пока не уперлись в 200 мегабит.

Ну тут дык легко было решено замутить гигабит. Поставили гигабитный свич, карту и запустили. Результаты неодназначны. С одной стороны по вечерам пиковая нагрузка часто переходит сумарный порог в 30 Мегабайт в секунду улетающего трафика к пользователям. Тобишь гигабит работает. И это есть гуд. С другой стороны вечером один клиент не может выжать к себе по самбе более чем 3-4 мегабайта в секунду. А в ситуации затишья максимум выжмешь 5-7 мегабайт в секунду. Как будто что то шейперит трафик на одного клиента. Клиент самбы под линухом так же тормозит. Клиент самбы под линухом с гигабитным аплинком в легкую дает по самбе мегабайт 25 в секунду что есть показатель что проблемы на стыке 100-1000.

В тоже время если качать не по самбе а по ftp то при качании с виндов получаешь где-то 4-5 мегабайт в секунду, а при качании из Линуха легко достигается пиковая скорость 10 мегабайт в секунду когда аплинк свободен. Так значит может же зараза такая, если захочет.

Всякие тюнинги самбы были опробованы и безрезультатны. Стек тоже крутили но не настолько плотно.

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

Вообщем какие есть народные мудрости про лечение гибридных (100-1000Мегабит) проблем?

[Ptizz]

Мир,труд,май....;)

[Guest]

Мир,труд,май....;)

А для тупых?

[Guest]

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

[NorN]

Перетяните гигабитный линк! :-)

[Guest]

:)

[shuras]

Перетягивать тут нечего. Даже на нормальном пачкорде с метра полтора длинной таже байдень. Патчи разные юзали и свичи тоже. Байда неистрибима и связана очевидно с какими-то таймингами/окнами TCP. Чуствую придется залезать в Ethereal поуши.

То бишь предлагаете роутер вместо свича использовать? Хммм. Изврат имхо но может сработать. Только гемору необобратся. А более правильнее решение какое-нибудь?

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

[NorN]

Давайте разберёмся, чтобы было понятней:

вы писали: "Поставили гигабитный свич, карту и запустили."

Вопрос: что за карту и куда? Игральную что ли?

Вы писали:"пиковая нагрузка часто переходит сумарный порог в 30 Мегабайт в секунду улетающего трафика к пользователям. Тобишь гигабит работает. И это есть гуд."

Вопрос: как из суммарной нагрузки в 30 мегабит вы определили, что работает гигабит. На этом месте вообще прослеживается большое количество информационного шума! И ещё, это есть гуд потому что сеть работает или потому что достигнута скорость в 30 мегабит?

вы писали:"Клиент самбы под линухом с гигабитным аплинком в легкую дает по самбе мегабайт 25 в секунду что есть показатель что проблемы на стыке 100-1000."

Вопрос: не понял! Как вы вывели, что проблема на стыке 100-1000??? Скорость не превышает 25 мегабит, а вы про стык говорите.

вы писали: " а при качании из Линуха легко достигается пиковая скорость 10 мегабайт в секунду когда аплинк свободен."

Вопрос: разве для гигабита пиковая 10 мегабит? Я всегда думал, что для гигабита пиковая 1000 мегабит :-) ничего не понимаю!

 

 

P.S. пожалуйста опишите ситуацию заново, не применяя альтруистский стиль изложения. Просто по пунктам - что есть и что надо, желательно, без большого количества наречий.

И вот ещё:

вы писали: "Как будто что то шейперит трафик на одного клиента."

Вопрос: скорее не на клиента, а на поток.

[chucha]

А злобные админы разницу между мегабайтами и мегабитами знают ?

[NorN]

А злобные админы разницу между мегабайтами и мегабитами знают ?

Вот у злобных адниминов и поинтересуйся.

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

В тоже время если качать не по самбе а по ftp то при качании с виндов получаешь где-то 4-5 мегабайт в секунду, а при качании из Линуха легко достигается пиковая скорость 10 мегабайт в секунду когда аплинк свободен. Так значит может же зараза такая, если захочет.

ну и о чём это? 10 мегабайт - это пиковая? или 10 мегабайт пиковая?

Кажется автор и сам запутался и меня запутал. Конечно, теперь я вижу почему ничего не понятно, то скорость измеряется в мегабитах, то в мегабайтах. :-))

Давайте уже примем цену деления в 1 MBit.

[shuras]

Все просто. Как уже я написал скорость исходящего с сервера трафика превышает 30 Мегабайт/сек что есть порядка 250 Мегабит/сек. Если вы читаете невнимательно то извиняйте.

Скорость скачивания клиентом на винде по самбе порядка 40-50 Мегабит, скорость скачивания по самбе на линухе примерно такае же, скорость по фтп скачивания на линухе примерно 90 мегабит, скорость скачивания по фтп на винде примерно 50 мегабит.

Скорость скачивания по самбе на линухе через гигабитный линк примерно 300-400 Мегабит. Скорость качания виндой через гигабит пока не меряли но скоро померяем.

[NorN]

Окей, я понял.

Вопрос: стоят ли на протяжении 100-1000 кикие-либо роутеры? Если стоят, может проблема в, некорректно настроенном, QoS? Советую, так же, удалить из винды QoS, именно удалить, а не отключить снятием флажка.

 

Ещё вариант: опишите конфигурацию сервера. Возможно, при отстутствии Raid массива сервер просто физически не может дать более 250Mbit. Скорости современных венчестеров редко привышает 45MByte/s а вы хотите 1GBit через магистрали мат.платы. и на PCI :-))

Расслабьтесь, вы не там ищете траблу. Сделайте Raid 0 на 4-х дисках, и будет вам счастье. Это, справедливо, если сейчас массива нету. (такие тонкости желательно было уточнять сразу, а приходится выяснять по ходу)

И ещё: попробуйте в несколько потоков покачать по самбе, результат расскажите.

[shuras]

Роутеров не стоит. Стоят лишь свичи причем пробовали даже клиентские машины подключать к головному, в качестве которого тоже разные использовались. (Dlink и 3Com).

Винты не тормозят. Стоит штук 8 винтов ide и страйпинг на двух читах скайзевых. Более того тесты проводим на файлах метров по 100-150 метров по нескольку раз что при размере памяти в два гига обеспечивает чтение чисто из кэша где скорость чтения равна скорости чтения из памяти.

Несколько потоков по самбе пробовали и на глаз не какит. По ftp пробовал качалками типа регета никаких преимуществ не получается. Ощущение что как шейпинг по ip.

QoS на этой неделе попробую отключить. Посмотрим что получится.

[NorN]

Я вижу следующую модель:

 

________1000Mbit____1000-100 Mbit____100Mbit

Server-------------------------Switch--------------------------Klient

 

Какое сетевое оборудование на стороне сервера клиента, и на переходе (производитель, модель)?

 

Фулдуплекс включён? (на всякий случай спросил)

[Guest]

На всякий случай, МТУ на клиентской винде на сетевой интерфейс правильно стоит?

[NorN]

Всмысле правильно? :-)

[shuras]

Модель правильная. В упрощенной форме так и тестировалось и даже в такой простой схеме такая фигня. Обородувание точно не вспомню. Но свичи пользовались Dlink и 3ком. На сервере стоял две разные гигабитные сетевухи от 3ком на разных чипсетах. На клиентской стороне чего только не стояло.

А как MTU может неправильно стоять?

Фулдуплекс включен. И ФлоуКонтрол тоже.

Имхо мы куда-то не туда уходим. Думаю что железо ровным счетом тут непричем.

Проблема в стеках/протоколах.

[shuras]

Очередной разбор полетов.

Вчера значит гоняли клиента виндового на гигабитном аплинке. Как и ожидалось на гигабите и ftp и самба проблемы с низкой скоростью не имеют. В легкую достигается 200 мегабит в секунду.

Сделал дамп передачи файла по ftp в условиях ста мегабит. Глянул ethereal'ом.

Ситуация следующая. Устанавливается окно тысяч где-то на 900. Идет передача сегментов. Окно не скользит, а направленно уменьшается на скорости 100 мегабит. Доходит до нуля и бац - следующее подтверждение со стороны клиента посылается через 150 милисекунд. Вот это и есть причина тормозов.

Потом следует установка окна приема на 90 тысяч. Прием на полной скорости до нуля. Как на ноль окно село так винда тормозит 50 милисекунд. После этого все повторяется по новой.

Вот такой лесенкой график сиквенсов и двигается.

Есть мысли какие-нибудь? Я просто слабо в стеках и tcp пока разбираюсь. Было бы интересно услышать мнения. Это конжектион контрол так развлекается?

[NorN]

:-)) shuras, так и должно быть размер окон не постоянный (слышал, что только у винды так). Дело в том, что ОС как бы пытается подстроиться под соединение, это система – “медленный старт”, создана как раз для того, чтобы получить максимальную производительность при переходе из быстрого сегмента в медленный и наоборот (в нашем случае 1000-100). Когда приемлемый размер окна определится, то и будет максимальная скорость.

Задержки быть должны, они быть обязаны! Эта задержка – ожидание подтверждения. (Теоретически, если её убрать, скорость возрастёт, но качество передачи не гарантированно). Как только подтверждение о получении сегментов придет, отправляется ещё одно окно. В данном случае определяется минимальная задержка в 17,4мс. Но у вас чего-то они большиваты. ОБЯЗАТЕЛЬНО сделайте с клиента ping до сервера Server -n 1000 -l 1400 и результат расскажите, посмотрим, какие задержки. У меня такое ощущение, вы либо поиграли с твикером, либо попали на палёвое оборудование. Кстати, винду переустанавливать на сервере пробовали, если конечно там винда? И ещё, вы же сказали, что в лёгкую достигается скорость 200Mbit на клиента! Так чего ещё для счастья надо-то?

 

P.S. ну ё-ё-ё RFC пересказал… shuras, RTFM!

[NorN]

Настаиваю о переноси этого топика в форум Hardware.

Хоть отвечать не я один буду, а то тат мало кто бывает.

[shuras]

На сервере Линукс. Настройки на момент тестирвания все по умолчанию.

Клиент в основном винда под нее и подстраиваемся.

В задержка может быть ожиданием подтверждения только если эта время ожидания плавает. Поскольку в анализе видно однозназначно что это время варьируется.

Вообще я пожалуй вырежу кусочек из дампа на пару мегов и выложу на всеообщее рассмотрение. Оттуда ситуация будет видна.

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

Статитсика по пингу round-trip min/avg/max = 0.4/0.7/21.0 ms

[NorN]

Пинг нормальный, 0.7 - хороший результат.

Всё же непонял я вас, вы так пишите... Тяжело читать.

В задержка может быть ожиданием подтверждения только если эта время ожидания плавает

Хотите сказать, что оно у вас стабильно на одном уровне стоит? Сколько?

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

:-) я же объясняю, так и должно быть. Окно - это типа буфера. Когда окно полностью ушло, получатель говорит, что окно = 0 байт, значит, получатель останавливает передачу и должен подтвердить корректное получение окна ACK ответом. Вот здесь и задержка.

[shuras]

Хммм. Не знал что так принято. Мне представлялось что должно быть скользящее окно, размер которого подстраивается в зависимости от потерь.

Да написал кривовато. Когда писал я имел ввиду что после передачи более короткого окна идет и более короткая пауза. Если бы ожидали прихода потерянного в окне пакета тогда бы пауза после любого окна была бы поменьше.

Ну да ладно. Щас положу дамп.

[NorN]

Хммм. Не знал что так принято. Мне представлялось что должно быть скользящее окно, размер которого подстраивается в зависимости от потерь.

Ну почти так, в зависимости от задержки. Оно и так скользящее. Говорил же это - "медленный старт".

[shuras]

Оки. Щас буду рюхать медленный старт. Видимо я его неправильно себе представлял.

А вот tcp дамп на полтора метра:

ftp://194.67.66.158/upload/shuras/PacketD...session.cut.rar