[isup]

Помогите понять почему

Время от времени появляется такая ситуация на 5 - 10 минут вечером в это же время многие жалуются на потери пакетов

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 728.537ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 368.519ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 368.519ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 188.510ms

.....................................

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 32.502ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 852.544ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 852.544ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 664.534ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 0.500ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 0.500ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 0.500ms

А дальше все отлично по 0.500ms

И так на любой хост на устройстве eth0 (побит на вланы)

В топе в этот момент ничего не меняется по iptraf тоже нет никаких всплесков

top - 00:35:29 up 1 day, 1:24, 1 user, load average: 0.24, 0.15, 0.10

Tasks: 89 total, 2 running, 87 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.6%us, 0.2%sy, 0.0%ni, 92.7%id, 0.8%wa, 0.9%hi, 4.8%si, 0.0%st

Cpu1 : 0.6%us, 0.3%sy, 0.0%ni, 83.2%id, 0.0%wa, 3.3%hi, 12.7%si, 0.0%st

Mem: 1539588k total, 900136k used, 639452k free, 209568k buffers

Swap: 1052216k total, 0k used, 1052216k free, 221012k cached

Шейпер

Основные 2 класса

tc qdisc add dev eth0 root handle 1: htb default 1000

tc class add dev eth0 parent 1: classid 1:1 htb rate 18300kbit quantum 18000 # burst 20k

tc class add dev eth0 parent 1: classid 1:2 htb rate 70000kbit quantum 18000 # burst 20k

tc class add dev eth0 parent 1:1 classid 1:1000 htb rate 16kbit quantum 1500 # DEFAULT CLASS

Абонентские

tc class add dev eth0 parent 1:2 classid 1:4216 htb rate 16kbit ceil 4096kbit quantum 3000 # burst 12

tc filter add dev eth0 protocol 802.1q parent 1: prio 2 u32 match ip dst 10.0.40.216 at 20 flowid 1:4216

tc filter add dev vlan740 parent ffff: protocol ip u32 match ip src 10.0.40.216 police rate 1024kbit burst 128k drop flowid :4216

И так на каждого всего 400

На сетевой работают разные вланы абсолютно одинаковая проблемма на всех вланах

Сначала подумал на сетевую, поменял - не помогло

Порт свича и патч корд - не помогло

Сам свитч (пользуясь случаем) - - не помогло

Заметил очень интересную особенность когда переписал vlan с другой сетевой на эту сетевую с ним началась таже история

 

 

 

 

 

 

 

[Ainy]

На трафик смотрел(глазами всмысле)? На статистику на интерфейсе этом?

[marikoda]

Заметил очень интересную особенность когда переписал vlan с другой сетевой на эту сетевую с ним началась таже история

flow control в каком состоянии?

[isup]

Спасибо

flow control в каком состоянии?

На свиче сейчас включил, на сервере сейчас буду разбиратся как

 

На трафик смотрел(глазами всмысле)? На статистику на интерфейсе этом?

До iptraf-ом количество pps и траффик. Оно в этот момент не растет, даже немного снижается

Также снимаются графики Cacti траффик, pps, загрузка cpu и памяти (всплесков нет)

 

net.netfilter.nf_conntrack_max = 65536

net.netfilter.nf_conntrack_count = до 30000 бывало и больше

net.netfilter.nf_conntrack_buckets = 8192

Изменено 6 октября, 2010 пользователем isup

[photon]

tc filter add dev vlan740 parent ffff: protocol ip u32 match ip src 10.0.40.216 police rate 1024kbit burst 128k drop flowid :4216

Подозреваю, что значение burst надо побольше поставить. 128K для 1Мбит/с это нормально, но для скоростей в десятки мегабит, burst должен быть 1Mb, а то и больше. Либо надо перейти на шейпинг вместо полисинга. Другим узким местом могут быть rx/tx rings у сетевух. Их можно увеличить с помощью ethtool.

Изменено 6 октября, 2010 пользователем photon

[isup]

tc filter add dev vlan740 parent ffff: protocol ip u32 match ip src 10.0.40.216 police rate 1024kbit burst 128k drop flowid :4216

Подозреваю, что значение burst надо побольше поставить. 128K для 1Мбит/с это нормально, но для скоростей в десятки мегабит, burst должен быть 1Mb, а то и больше. Либо надо перейти на шейпинг вместо полисинга. Другим узким местом могут быть rx/tx rings у сетевух. Их можно увеличить с помощью ethtool.

Спасибо

Увеличить буферы пока не могу

Стояла intel пока поставил дурную на марвеле. Но ситуация 1 в 1

Подскажите пож как перейти на шейпинг. Я думал что сейчас все шейпается

Еще подскажите 400 классов без hashing tables это нормально ? загрузка si до 25%

[photon]

Подскажите пож как перейти на шейпинг. Я думал что сейчас все шейпается

Еще подскажите 400 классов без hashing tables это нормально ? загрузка si до 25%

Я бы уже ввел хэширование, т.к. 400 правил в обе стороны -- это много. Для перехода на шейпинг надо знать, с какого интерфейса отправляется исходящий трафик, который сейчас приходит на vlan740 (где полисинг). Подозреваю, что это eth1. На этом интерфейсе и надо делать шейпинг, т.е. создавать filter, class, leaf qdisc для каждого пользователя, по аналогии с тем, как это сделано на eth0.

Изменено 6 октября, 2010 пользователем photon

[isup]

Заметил очень интересную особенность когда переписал vlan с другой сетевой на эту сетевую с ним началась таже история

flow control в каком состоянии?

Включение flow control не помогло :(

[marikoda]

Включение flow control не помогло :(

А какие сетевые вообще?

 

Что говорит

cat /proc/interrupts

 

[isup]

Включение flow control не помогло :(

А какие сетевые вообще?

Что говорит

cat /proc/interrupts

cat /proc/interrupts

s1:~ # cat /proc/interrupts

CPU0 CPU1

0: 145 1 IO-APIC-edge timer

1: 0 2 IO-APIC-edge i8042

2: 0 0 XT-PIC-XT cascade

5: 0 0 IO-APIC-fasteoi ohci_hcd:usb1

6: 0 5 IO-APIC-edge floppy

7: 1 0 IO-APIC-edge parport0

8: 0 2 IO-APIC-edge rtc

10: 165281713 4778 IO-APIC-fasteoi HDA Intel, eth0

11: 54 239808998 IO-APIC-fasteoi sata_nv, ehci_hcd:usb2, eth1

12: 0 4 IO-APIC-edge i8042

14: 53135 3051 IO-APIC-edge libata

15: 0 0 IO-APIC-edge libata

220: 1920770 701 PCI-MSI-edge eth2

NMI: 0 0

LOC: 4779726 4779706

На вход временное решение realtec 8139 (потерь на ней нет)

На выход вместо intel pro пока поставил marvell ситуция 1 в 1

На сетевой работают разные вланы абсолютно одинаковая проблемма на всех вланах

Сначала подумал на сетевую, поменял - не помогло

Изменено 6 октября, 2010 пользователем isup

[isup]

Помоему сам разобрался

htb default class был 8k увеличил до 64k. Он наверно забивался и хождение arp who-has и arp-rely было затруднено.

Вопрос №2 можно ли увидеть кто или что забивает default class?

[Nallien]

создайте отдельный класс с высоким приоритетом и скоростью на все локальные нужды (ARP, DHCP, DNS, ICMP, TCP, SSH... и т.д.). дефолт должен играть роль буфера для классифицированного трафика, то есть того о котором вам ничего не известно и/или на качество которого наплевать.

[isup]

создайте отдельный класс с высоким приоритетом и скоростью на все локальные нужды (ARP, DHCP, DNS, ICMP, TCP, SSH... и т.д.).

Спасибо, в точку. Особенно про arp.

Другие наверно не надо т.к. пакет с ip адреса будет попадать в свой класс (тарифный план) а протокол, например dns в другой класс (который 1 на всех) и который 1 пользователь может забить так что будет тормозить у других.