Главная » Форум » Gentoo Linux » Системное администрирование

Ограничение скорости для ip адреса

dolphin 11 декабря, 2009 - 00:11

есть шлюз который пропускает абонентов в интернет
был настроен iptables и iproute2 для ограничения скоростей (htb или cbq)
все впринцепе работало нормально до того момента как увеличилось число абонентов
тогда канал расширили со 100 до 300 мегабит

но по факту в часы пик загрузка канала была на уровне 110 мегабит

началось следующее один из процессов ksoftirq занимал в top 100% после попытки разнести сетевухи по разным процам
картина изменилась но не сильно в итоге если я удаляю правила ограничения скоростей то процессор разгружается
а загрузка канала тогда составляет как раз положенные 300 мегабит

может ли ктонибудь посоветовать с помощю чего можно ограничивать скорость абонентам или может я просто не так пользую iproute2

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 300mbps

для каждого абонента

/sbin/tc class add dev eth0 parent 1:1 classid 1:(id абонента) htb rate 256bit ceil (СКОРОСТЬ)kbit prio 0
/sbin/tc filter add dev eth0 parent 1:0 protocol ip pref (id абонента) u32 match ip dst (ИП абонента) classid 1:(id абонента)

абонентов около 1500

‹ вотпрос про kvm Вопрос о сервисе dbmail ›
»

Проц какой? Сетевые? У меня

Автор alexpro, дата создания 11 декабря, 2009 - 01:00.

Проц какой? Сетевые?
У меня тоже прилично полос определено, правда, я fw правило использую. Особых проблем не испытываю, но, правда, у меня 2 сервера на ~2300 абонентов.

»

у меня тоже на самом деле у

Автор dolphin, дата создания 11 декабря, 2009 - 01:32.

у меня тоже на самом деле у мен ятоже два сервера просто на втором седят прмые адреса и adsl абоненты
всего человек 500 там соответственно проблем нет

а даже если бы и были то сервера отличаются друг от друга только версией ядра

процы 2 X Xeon 2 ГГц 2 гига оперативы сетевухи Интел гигабитные онбордные

gate01 ~ # lspci -k | grep -i -A1 ethernet
04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
	Kernel driver in use: e1000e
04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
	Kernel driver in use: e1000e

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

http://www.gentoo.ru/node/16996

»

Нужно поставить oprofile,

Автор alexpro, дата создания 11 декабря, 2009 - 02:11.

Нужно поставить oprofile, посмотреть, что именно ест softirq больше всего. Для такой конфигурации нагрузка смешная, у нас на такой нагрузке Core2Duo стоял с обычной асусной десктопной мамой. Поначалу были проблемы с softirq, решили оптимизацией правил iptables и фильтров htb.

»

Кстати, вот это (выделено

Автор alexpro, дата создания 11 декабря, 2009 - 12:26.

Кстати, вот это (выделено жирным):

/sbin/tc class add dev eth0 parent 1:1 classid 1:(id абонента) htb rate 256bit ceil (СКОРОСТЬ)kbit prio 0[]

несколько смущает. Зачем такой маленький rate? При таком раскладе htb у вас будет всегда считать, есть ли возможность отдать ceil или нет. Т.е. - созданы такие условия, что rate превышен постоянно. Уж если есть необходимость в rate != ceil, то значение rate должно быть более вменяемо, ну хотя бы 32Kbit, а лучше 64Kbit.
Кстати, насколько много фильтров одновременно ограничивают полосу во время большой загрузки?

»

rate == ceil?

Автор pva, дата создания 11 декабря, 2009 - 16:14.

А как избежать условия rate != ceil? Чтобы управлять трафиком суммарный по всем абонентам rate не должен превышать общей пропускной способности канала. Так как тарифы в 1-10Мбит не редкость, rate всегда != ceil.

»

Я же не говорил, что его надо

Автор alexpro, дата создания 11 декабря, 2009 - 17:30.

Я же не говорил, что его надо избегать :) Но rate 256bit - это уж совсем перебор. Вы представьте себе, как будет вести себя htb, как только клиент хоть что-нибудь потянет? У меня сейчас общий канал 120Мбит/с, и значение rate для любой полосы нигде не стоИт ниже 128Kbit.
2300*128=это почти 300 Мбит, но все равно все прекрасно работает, потому что даже в самый что ни на есть пик не работают все одновременно. Как показывает практика (у нас) - из 2300 в на пике нагрузки активно ограничивается не более 300-350 полос. Да и "полочки" на канале не наблюдается, ибо если хоть иногда бывает "полочка" - значит, канал надо однозначно расширять.
Подход к суммарным rate с такой точностью, ИМХО, оправдан только в том случае, если каждая полоса гарантированно берет то, что ей причитается ежедневно, и если суммарная емкость полос равна общей емкости канала.

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

»

alexpro написал(а): Я же не

Автор dolphin, дата создания 11 декабря, 2009 - 18:04.
alexpro написал(а):
Я же не говорил, что его надо избегать :) Но rate 256bit - это уж совсем перебор. Вы представьте себе, как будет вести себя htb, как только клиент хоть что-нибудь потянет? У меня сейчас общий канал 120Мбит/с, и значение rate для любой полосы нигде не стоИт ниже 128Kbit.
2300*128=это почти 300 Мбит, но все равно все прекрасно работает, потому что даже в самый что ни на есть пик не работают все одновременно. Как показывает практика (у нас) - из 2300 в на пике нагрузки активно ограничивается не более 300-350 полос. Да и "полочки" на канале не наблюдается, ибо если хоть иногда бывает "полочка" - значит, канал надо однозначно расширять.
Подход к суммарным rate с такой точностью, ИМХО, оправдан только в том случае, если каждая полоса гарантированно берет то, что ей причитается ежедневно, и если суммарная емкость полос равна общей емкости канала.

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

я поменяю сегодня rait и посмотрю...

на сколько я помню тот ман (или как я его понял) особенно не пренципиально что там стоит за исключением того что в сумме не должно
привышать возможного

а если поможет изменение rait то тогда мне не понятна в разница между 256bit и 256Kbit т.к. я её в любом случае привышаю включая большей ceil ...

если бы параметр rait не был бы обязательным я его бы вообще не ставил

»

Все-таки советую

Автор alexpro, дата создания 11 декабря, 2009 - 18:19.

Все-таки советую воспользоваться oprofile. Ведь помимо htb, на сервере наверняка применяется iptables? А iptables тоже любит кушать softirq.
rate - это параметр, задающий скорость потока, выделяемого в класс. Ceil задает максимально возможную скорость потока, которую может получить класс в случае, если ее есть возмножность выделить из родительских классов. Если парамерт ceil не указывать вообще, то ceil будет равен rate, т.е. - параметр ceil не является обязательным.

Рекомендую хотя бы несколько дней в пиковое время посмотреть на то, сколько классов активно ограничивают скорость. Это тоже поможет в оптимизации нагрузки. Мощности железа должно хватить. Ну, и еще раз, не стОит пренебрегать iptables.

»

с iptables я смотрел в своё

Автор dolphin, дата создания 11 декабря, 2009 - 19:38.

с iptables я смотрел в своё время были такие-же проблемы в итоге ушол просто от разрешающих правил
поставил только запреты....

а в итоге все стало ещё проще.... абонентам стали отключать интрнет на ближайшем свиче третьего уровня
а в iptables в цепи FORWARD порядка пяти правил

»

Hashing filters

Автор pva, дата создания 11 декабря, 2009 - 16:04.

Не очень ясно, как и что у вас настроено. Попробуйте покурить на тему:
http://lartc.org/howto/lartc.adv-filter.hashing.html

»

Что касается rait и cailна

Автор dolphin, дата создания 11 декабря, 2009 - 17:53.

Что касается rait и cail
на соколько я помню когда писал скрипт загрузки я читал ман и там было написанно что rait
это гарантированная скорость а ceil это максимально возможная скорость для класса

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

Oprofile поставил как начнется нагрузка буду смотреть что происходит

»

Если поставил oprofile, оно и

Автор alexpro, дата создания 11 декабря, 2009 - 18:21.

Если поставил oprofile, оно и сейчас уже будет приблизительно видно, кто и сколько ест.

»

Не магу до конца разобраться

Автор dolphin, дата создания 11 декабря, 2009 - 18:44.

Не магу до конца разобраться на что смотреть в oprofile

Не могли бы вы подсказать...

»

Ядро собирали сами? Если нет,

Автор alexpro, дата создания 11 декабря, 2009 - 19:08.

Ядро собирали сами? Если нет, то надо собрать самому, и загрузиться с него.
Потом

opcontrol --setup /usr/src/linux/vmlinux
opcontrol --start-daemon
opreport -l /usr/src/linux/vmlinux

Это по-простому. Если сложнее, надо курить документацию и гуглить. Рассказывать - это целую статью писать надо.

»

ядро пересобрал ещё когда

Автор dolphin, дата создания 11 декабря, 2009 - 19:55.

ядро пересобрал ещё когда ставил
я в коммандах запутался
все работает ...

gate01 ~ # opreport -l /usr/src/linux/vmlinux  | head
Overflow stats not available
CPU: Core 2, speed 1994.74 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples  %        symbol name
37467391 38.3182  u32_classify
3174444   3.2465  ipt_do_table
2860118   2.9251  net_tx_action
2679537   2.7404  __do_softirq
1989864   2.0350  tc_classify_compat
1748211   1.7879  __qdisc_run
1591479   1.6276  e1000_clean

u32_classify я так понял больше всего сейчас кушает....
а к чему он относится к фильтрации для ограничении скорости?

»

Вот буквально

Автор dolphin, дата создания 11 декабря, 2009 - 22:36.

Вот буквально сейчас
ksoftirqd/3 - 78%

gate01 ~ # opreport -l /usr/src/linux/vmlinux  | head -n20
Overflow stats not available
CPU: Core 2, speed 1994.74 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples  %        symbol name
159105399 39.9683  u32_classify
13392497  3.3643  ipt_do_table
13135148  3.2996  mutex_spin_on_owner
9893536   2.4853  tc_classify_compat
9075967   2.2799  net_tx_action
8465610   2.1266  __do_softirq
5991468   1.5051  __qdisc_run
5254470   1.3200  __debug_check_no_obj_freed
4232986   1.0634  mwait_idle
4207407   1.0569  e1000_clean
4107636   1.0319  ip_route_input
3991155   1.0026  debug_object_deactivate
3668430   0.9215  e1000_xmit_frame
3161975   0.7943  e1000_intr_msi
2919759   0.7335  e1000_clean_rx_irq
2862682   0.7191  dev_queue_xmit
2819386   0.7082  __schedule
»

при отключенных ограничениях

Автор dolphin, дата создания 15 декабря, 2009 - 00:01.

при отключенных ограничениях скоростях показатели opreport
не изменились

немного изменил фильтр сделал так

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst (ип адрес) flowid 1:(ид абонента)

сейчас вроде час пик ksoftirqd/* не более 5 процентов и у абонентов скорость по тарифу ...
посмотрим что будет, но я честно говоря сомневаюсь

»

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".