Доброго дня!Подскажите, какие настройки ядра и системы (sysctl?) в целом влияют на скорость входящего трафика на сервер под управлением FreeBSD 6.1 (media: Ethernet autoselect (100baseTX <full-duplex>))
Явным образом ширина канала не режется ни на сервере ни на свитчах/роутерах/прочее.
Куда копать?
>Доброго дня!
>
>Подскажите, какие настройки ядра и системы (sysctl?) в целом влияют на скорость входящего трафика на сервер под управлением FreeBSD 6.1 (media: Ethernet autoselect (100baseTX <full-duplex>))
>
>Явным образом ширина канала не режется ни на сервере ни на свитчах/роутерах/прочее.
>
>
>Куда копать?можнор изврашаться с:
icmp
tcpно реалный ответ - никакие. от "впаривания" лишнего трафика никто не застрахован.
PS "скорость трафика" - это что-то новое
>[оверквотинг удален]
>>Куда копать?
>
>можнор изврашаться с:
>icmp
>tcp
>
>но реалный ответ - никакие. от "впаривания" лишнего трафика никто не застрахован ибо не ты им упралвяшь.
>
>
>PS "скорость трафика" - это что-то новое
>
>можнор изврашаться с:
>icmp
>tcp
>
>но реалный ответ - никакие. от "впаривания" лишнего трафика никто не застрахован.Дело не в этом, а в том, что скорость слишком низкая, как будто канал "зажали", но он даже на 10% не загружен. Вот и думаю, может чего перемудрили с настройками в ядре или еще чего?
>PS "скорость трафика" - это что-то новое
Ага, пойду патент получать на изобретение.
>[оверквотинг удален]
>>можнор изврашаться с:
>>icmp
>>tcp
>>
>>но реалный ответ - никакие. от "впаривания" лишнего трафика никто не застрахован.
>
>Дело не в этом, а в том, что скорость слишком низкая, как
>будто канал "зажали", но он даже на 10% не загружен. Вот
>и думаю, может чего перемудрили с настройками в ядре или еще
>чего?в каком маштабе времени смотрите?
какую скорость имеете ввиду?
что именно качаете?
>>PS "скорость трафика" - это что-то новое
>
>Ага, пойду патент получать на изобретение.
>в каком маштабе времени смотрите?
>какую скорость имеете ввиду?
>что именно качаете?В реале + среднее за 5 минут (MRTG) + сутки + недели + другое
Имхо, какое это имеет значение? Ибо все тесты, что могли проделать - сделали.Разница в скорости закачивания файла достигает 4x-5x с соседним сервером, который имеет аналогичное подключение (один-в-один) через аналогичный (тот же) свитч/роутер/канал.
Качали с FTP, HTTP от 5Мб до 500Мб с разных серверов, расположенных в разных точках мира.
Вот и сейчас качается:
=> Attempting to fetch from http://nchc.dl.sourceforge.net/sourceforge/clamav/.
clamav-0.94.2.tar.gz 73% of 21 MB 17 kBps 05m28sПри канале до аплинка в 100Мб/сек
вы вообще можете здраво и четко изложить схему подключения и проблему конкретно.а не вывалифать тупо дамп своих мыслей прямо из мозга )
нихера же не понятно что у вас и где.
>вы вообще можете здраво и четко изложить схему подключения и проблему конкретно.
>
>а не вывалифать тупо дамп своих мыслей прямо из мозга )
>
>нихера же не понятно что у вас и где.Прочитайте первый пост, если не понятно, тогда пишу еще раз от ОБРАТНОГО.
Интересует момент, возможно ли, на ПРОГРАММНОМ или СИСТЕМНОМ уровне (не на АППАРАТНОМ) ограничить скорость закачки файлов на сервер без того, чтобы урезать искусственно ширину канала с помощью IPFW или SQUID (чего-то там еще вероятного доп. софта) через настройки ядра и/или systcl ?
>[оверквотинг удален]
>>
>>нихера же не понятно что у вас и где.
>
>Прочитайте первый пост, если не понятно, тогда пишу еще раз от ОБРАТНОГО.
>
>
>Интересует момент, возможно ли, на ПРОГРАММНОМ или СИСТЕМНОМ уровне (не на АППАРАТНОМ)
>ограничить скорость закачки файлов на сервер без того, чтобы урезать искусственно
>ширину канала с помощью IPFW или SQUID (чего-то там еще вероятного
>доп. софта) через настройки ядра и/или systcl ?можно. даже средствами ipfw можно шейпить по адресам/сетям/портам :)
>можно. даже средствами ipfw можно шейпить по адресам/сетям/портам :)Хочу уточнить, если все-таки НЕ брать во внимание IPFW, можно это делать иными средствами?
Дайте, пожалуйста, пару примеров или наводку для поиска)))
>>можно. даже средствами ipfw можно шейпить по адресам/сетям/портам :)
>
>Хочу уточнить, если все-таки НЕ брать во внимание IPFW, можно это делать
>иными средствами?
>Дайте, пожалуйста, пару примеров или наводку для поиска)))altq
>[оверквотинг удален]
>>
>>нихера же не понятно что у вас и где.
>
>Прочитайте первый пост, если не понятно, тогда пишу еще раз от ОБРАТНОГО.
>
>
>Интересует момент, возможно ли, на ПРОГРАММНОМ или СИСТЕМНОМ уровне (не на АППАРАТНОМ)
>ограничить скорость закачки файлов на сервер без того, чтобы урезать искусственно
>ширину канала с помощью IPFW или SQUID (чего-то там еще вероятного
>доп. софта) через настройки ядра и/или systcl ?а чем по вашему отличается закачка файлов от прочих tcp соединений?
может тебя тупо режут на другой стороне?
>
>а чем по вашему отличается закачка файлов от прочих tcp соединений?ага)))
>может тебя тупо режут на другой стороне?
Исключено. Ибо проделали всевозможные тесты, качали файлы разного размера с разных точек мира. На разные сервера со схожими исходными настройками, и когда в пределах одного ДЦ через один и тот же свитч и роутер, при одной и той же ширине канала для серверов (host1 и host2), на выходе получаем для одних и тех же файлов разную скорость и соответственно разное время закачки, можем смело утверждать, что дело в чем-то другом.
host1 (eth1, 100baseTX <full-duplex>) => | S |
| (eth0, (1000baseTX <full-duplex>) | W |
| | I | => | ROUTER | => INTERNET
| | T |
| (eth0, (1000baseTX <full-duplex>) | C |
host2 (eth1, 100baseTX <full-duplex>) => | H |Скорость на eth1 для обоих серверов (host1 и host2), когда файл качается с host1 на host2 (или наоборот) поднимается до 5-6 мб/с.
altq вроде все-таки влияет на исходящий траф и по всей видимости дело не в нем.
The ALTQ framework provides several disciplines for queuing outgoing net-
work packets. This is done by modifications to the interface packet
queues.В чем еще может быть дело?
>[оверквотинг удален]
> | (eth0, (1000baseTX <full-duplex>) | W |
> | | I | => | ROUTER | => INTERNET
> |
>
>
> | T |
> | (eth0, (1000baseTX <full-duplex>) | C |
>host2 (eth1, 100baseTX <full-duplex>) => | H |
>
>
судя по схеме, ROUTER - это уже ваш провайдер?
кстате, host1 и host2 находятся в разных подсетях? т.е. трафик между ними проходит только через ROUTER или нет? свитч тупой или там на портах какие-то ограничения таки выставленны?
>судя по схеме, ROUTER - это уже ваш провайдер?
>кстате, host1 и host2 находятся в разных подсетях? т.е. трафик между ними
>проходит только через ROUTER или нет? свитч тупой или там на
>портах какие-то ограничения таки выставленны?свитч и роутер принадлежат провайдеру.
host1 и host2 в разных подсетях, трафик по внешнему интерфейсу (eth1) ходит через роутер.
свитч управляемый (cisco, точную модель не знаю), ограничения на трафик отсутствуют.
настройки портов свитча для host1 и host2 идентичны.
>>судя по схеме, ROUTER - это уже ваш провайдер?
>>кстате, host1 и host2 находятся в разных подсетях? т.е. трафик между ними
>>проходит только через ROUTER или нет? свитч тупой или там на
>>портах какие-то ограничения таки выставленны?
>
>свитч и роутер принадлежат провайдеру.
>host1 и host2 в разных подсетях, трафик по внешнему интерфейсу (eth1) ходит
>через роутер.
>свитч управляемый (cisco, точную модель не знаю), ограничения на трафик отсутствуют.
>настройки портов свитча для host1 и host2 идентичны.полосу провайдер нарезает для каждого хоста свою или одну на всех?
вместо подозрительного хоста подкиньте другую машинку, если результат тестов будет тот же - озадачить провайдера... интересно как это он объяснит ...
>полосу провайдер нарезает для каждого хоста свою или одну на всех?в данном случае для каждого хоста свою.
>вместо подозрительного хоста подкиньте другую машинку, если результат тестов будет тот же
>- озадачить провайдера... интересно как это он объяснит ...запланировали это уже.
а какие ещ все-таки могут быть варианты?
или настройки системы тут влиять не могут?
>а какие ещ все-таки могут быть варианты?
>или настройки системы тут влиять не могут?думаю нет.
разве что только косвенно, потому как, к примеру, и глюкавая сетевая и глюкавый патчкорд могут влиять на скорость ... увеличиваются потери и в итоге (субъективно) падает скорость.
ну или если сильно рыли настройки TCP/IP стека, может и тут проблема ... но думаю если рыли - то в курсе что и как выставляли и для чего это делали.... :)
>думаю нет.
>разве что только косвенно, потому как, к примеру, и глюкавая сетевая и
>глюкавый патчкорд могут влиять на скорость ... увеличиваются потери и в
>итоге (субъективно) падает скорость.
>ну или если сильно рыли настройки TCP/IP стека, может и тут проблема
>... но думаю если рыли - то в курсе что и
>как выставляли и для чего это делали.... :)благодарю за разъяснения.
после визита в ДЦ, надеюсь, ситуация прояснится.