Я пытаюсь настроить простое регулирование полосы пропускания на сервере Linux, и я сталкиваюсь с тем, что кажется очень странным, несмотря на кажущуюся тривиальную конфигурацию.
Я хочу сформировать трафик, поступающий на определенный IP-адрес клиента (10.41.240.240), до жесткого максимума 75 Кбит / с. Вот как я настроил шейпинг:
# tc qdisc add dev eth1 root handle 1: htb default 1 r2q 1
# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 75kbit
# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst
10.41.240.240 flowid 1:10
Чтобы проверить, я запускаю загрузку файла через HTTP с указанного клиентского компьютера и измеряю полученную скорость, глядя на Кб / с в Firefox.
Теперь поведение довольно загадочно: DL начинается со скоростью примерно 10 Кбайт / с и продолжает набирать скорость, пока не стабилизируется на уровне примерно 75 Кбайт / с (килобайт, а не килобит, как настроено!). Затем, если я начну несколько параллельных загрузок одного и того же файла, каждая загрузка стабилизируется на скорости около 45 Кбайт / с; Таким образом, совокупная скорость этих загрузок значительно превышает настроенный максимум.
Вот что я получаю, исследуя tc для получения отладочной информации
[root@kup-gw-02 /]# tc -s qdisc show dev eth1
qdisc htb 1: r2q 1 default 1 direct_packets_stat 1
Sent 17475717 bytes 1334 pkt (dropped 0, overlimits 2782 requeues 0)
rate 0bit 0pps backlog 0b 12p requeues 0
[root@kup-gw-02 /]# tc -s class show dev eth1
class htb 1:1 root rate 75000bit ceil 75000bit burst 1608b cburst 1608b
Sent 14369397 bytes 1124 pkt (dropped 0, overlimits 0 requeues 0)
rate 577896bit 5pps backlog 0b 0p requeues 0
lended: 1 borrowed: 0 giants: 1938
tokens: -205561 ctokens: -205561
class htb 1:10 parent 1:1 prio 0 **rate 75000bit ceil 75000bit** burst 1608b cburst 1608b
Sent 14529077 bytes 1134 pkt (dropped 0, overlimits 0 requeues 0)
**rate 589888bit** 5pps backlog 0b 11p requeues 0
lended: 1123 borrowed: 0 giants: 1938
tokens: -205561 ctokens: -205561
Чего я не могу понять, это вот что: почему я получаю «скорость 589888 бит 5pps» с конфигурацией «скорость 75000 бит, ceil 75000 бит»? Почему эффективная ставка намного превышает настроенную? Что я делаю не так? Почему он так себя ведет?
Пожалуйста, помогите, я в тупике. Спасибо, парни.
Вместо этого попробуйте использовать этот пример:
# tc qdisc add dev eth1 root handle 1: htb default 10
# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1Kbit ceil 35Kbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 35kbit
# tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10
# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 \
match ip dst 10.41.240.240 flowid 1:20
Это создает ведро htb с ограничением скорости 75 Кбит / с, а затем создает два sfq (qdisc с честной очередью) под ним.
По умолчанию все будут в первой очереди с гарантированной скоростью 1 Кбит и максимальной скоростью 30 Кбит. Теперь ваш IP-адрес 10.41.240.240 будет гарантированно иметь 35 Кбит и может занимать до 75 Кбит, если используется невыбранный трафик. Два соединения из .240 должны быть средними и одинаковыми для каждого соединения, а соединение между .240 и не .240 будет параллельным с соотношением очередей 35: 1.
Я вижу, что он не работает с апреля ... так что, надеюсь, эта информация по-прежнему ценится для вас.
Думаю, я вроде как решил проблему: мне нужно было привязать qdiscs / классы к устройству IMQ, а не к устройству ETH. Как только я это сделал, формирователь заработал.
Тем не мение!
Хотя я мог заставить формирователь ограничивать трафик, входящий в машину, я не мог заставить его справедливо разделять трафик (хотя я прикрепил SFQ к своему HTB).
Произошло следующее: я начал загрузку; он был ограничен 75 Кбайт / с. Теперь, когда я начал вторую загрузку, вместо того, чтобы равномерно разделить трафик между двумя сеансами DL (35 Кбайт / с + 35 Кбайт / с), скорость на первом сеансе почти не снизилась, а на втором сеансе были скудные 500 бит / с. Через пару минут разделение остановилось примерно на 65 Кбайт / с + 10 Кбайт / с. возмущенно Это не справедливо! :)
Итак, я разобрал свою конфигурацию, пошел дальше и установил ClearOS 5.2 (дистрибутив Linux с предварительно созданной системой брандмауэра), который имеет модуль формирователя трафика. Модуль использует настройку HTB + SFQ, очень похожую на то, что я настроил вручную.
Та же проблема справедливости! Общий лимит соблюдается хорошо, но справедливости нет! - две загрузки имеют одинаковую странную пропорцию 65/15, а не 35/35.
Есть идеи, ребята?
Это может быть связано с этим:
Из: http://www.shorewall.net/traffic_shaping.htm
Предупреждение для пользователей Xen
Если вы используете формирование трафика в своем домене dom0, а формирование трафика не ограничивает исходящий трафик должным образом, это может быть связано с «разгрузкой контрольной суммы» в вашем домене (ах). Проверьте вывод "shorewall show tc". Вот выдержка из вывода этой команды:
class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0
Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0)
rate 299288bit 3pps backlog 0b 0p requeues 0
lended: 53963 borrowed: 21361 giants: 90174
tokens: -26688 ctokens: -14783
В приведенном выше выводе есть две очевидные проблемы:
Эта проблема будет исправлена отключением "разгрузки контрольной суммы" в вашем domU с помощью утилиты ethtool. См. Инструкции в одной из статей о Xen.