2.6.29 потеря пакетов

[Ivan Rostovikov]

Перешел на Lenny. Собрал 2.6.29.

Машина используется как PPPoE NAS.

Примерно после 1000 соединений начинает спонтанно терять пакеты.

Загрузка интерфейсов примерно 300Мб

Общая загрузка ядер - не выше 3 %%

 

Раньше стояло 2.6.26 и таких проблем небыло.

Ядро собирал по умолчанию.

Какие опции ядра показать ?

 

[DemYaN]

Общая загрузка ядер - не выше 3 %%

в 3% все включено? и irq и softirq?

[Ivan Rostovikov]

system+user+nice

 

На 2.6.26 при прочих равных потерь небыло.

Edited April 20, 2009 by Ivan Rostovikov

[2c2i]

а netstat -i ошибки показывает на сетевухах?

[DemYaN]

какой процент загрузки softirq (si) был на 2.6.26, а какой сейчас?

[Ivan Rostovikov]

>а netstat -i ошибки показывает на сетевухах?

# uptime

18:02:34 up 1 day, 23:12, 1 user, load average: 0.02, 0.04, 0.07

# netstat -i | grep "eth. "

eth0 1500 0 2080556938 0 0 0 2063024926 0 0 0 BMRU

eth1 1500 0 2312754585 0 0 0 2331436831 0 0 0 BMRU

eth2 1500 0 2151313082 0 274 0 2265164304 0 0 0 BMRU

eth3 1500 0 2864110954 0 2539 0 2720237753 0 0 0 BMRU

 

Т.е. дробы есть но вроде немного... Или много ?

 

>какой процент загрузки softirq (si) был на 2.6.26, а какой сейчас?

 

Честно говоря кроме как top ни чем не смотрел.

Процессы ksoftirqd/* почти всегда загружены на 0. Иногда (очень редко) просксользнет 1.

Так было на 2.6.26, так же и сейчас.

 

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

:-(

[DemYaN]

в топе эти данные отображаются:

 

top - 18:28:46 up 53 days, 8:00, 3 users, load average: 0.51, 1.02, 1.11

Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.7%us, 0.7%sy, 0.0%ni, 92.4%id, 0.0%wa, 0.3%hi, 6.0%si, 0.0%st

Cpu1 : 0.3%us, 0.6%sy, 0.0%ni, 91.8%id, 0.0%wa, 0.6%hi, 6.6%si, 0.0%st

Cpu2 : 1.3%us, 1.0%sy, 0.0%ni, 91.0%id, 0.0%wa, 0.6%hi, 6.1%si, 0.0%st

Cpu3 : 1.3%us, 0.7%sy, 0.0%ni, 91.8%id, 0.0%wa, 0.7%hi, 5.6%si, 0.0%st

 

просто для 300М, 3% загрузки маловато

Edited April 20, 2009 by DemYaN

[Ivan Rostovikov]

>просто для 300М, 3% загрузки маловато

 

Вот типичная ситуация:

 

# ethstats | grep "eth.:"

eth0: 161.76 Mb/s In 300.00 Mb/s Out - 29984.0 p/s In 35908.0 p/s Out

eth1: 248.97 Mb/s In 108.34 Mb/s Out - 28410.0 p/s In 23553.0 p/s Out

eth2: 134.90 Mb/s In 186.59 Mb/s Out - 23079.0 p/s In 23608.0 p/s Out

eth3: 222.72 Mb/s In 214.32 Mb/s Out - 34958.0 p/s In 34699.0 p/s Out

 

top - 20:40:13 up 2 days, 1:50, 1 user, load average: 0.40, 0.46, 0.34

Tasks: 1342 total, 1 running, 1341 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.1%us, 0.5%sy, 0.0%ni, 98.8%id, 0.2%wa, 0.0%hi, 0.3%si, 0.0%st

Mem: 2074124k total, 814412k used, 1259712k free, 131628k buffers

Swap: 2650684k total, 0k used, 2650684k free, 148692k cached

 

# ping 195.21.238.1

PING 195.21.238.1 (195.21.238.1) 56(84) bytes of data.

ping: sendmsg: Operation not permitted

64 bytes from 195.21.238.1: icmp_seq=2 ttl=255 time=0.449 ms

64 bytes from 195.21.238.1: icmp_seq=3 ttl=255 time=0.458 ms

64 bytes from 195.21.238.1: icmp_seq=4 ttl=255 time=0.433 ms

64 bytes from 195.21.238.1: icmp_seq=5 ttl=255 time=0.489 ms

ping: sendmsg: Operation not permitted

64 bytes from 195.21.238.1: icmp_seq=7 ttl=255 time=0.420 ms

ping: sendmsg: Operation not permitted

64 bytes from 195.21.238.1: icmp_seq=9 ttl=255 time=0.419 ms

64 bytes from 195.21.238.1: icmp_seq=10 ttl=255 time=1.13 ms

64 bytes from 195.21.238.1: icmp_seq=11 ttl=255 time=0.652 ms

64 bytes from 195.21.238.1: icmp_seq=12 ttl=255 time=0.563 ms

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

64 bytes from 195.21.238.1: icmp_seq=16 ttl=255 time=0.433 ms

64 bytes from 195.21.238.1: icmp_seq=17 ttl=255 time=0.456 ms

64 bytes from 195.21.238.1: icmp_seq=18 ttl=255 time=0.513 ms

64 bytes from 195.21.238.1: icmp_seq=19 ttl=255 time=0.460 ms

^C

--- 195.21.238.1 ping statistics ---

19 packets transmitted, 13 received, 31% packet loss, time 18023ms

rtt min/avg/max/mdev = 0.419/0.529/1.133/0.185 ms

 

[disappointed]

ping: sendmsg: Operation not permitted

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

?

[Ivan Rostovikov]

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

65536

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

65536

 

Какой будет диагноз ?

Edited April 20, 2009 by Ivan Rostovikov

[2c2i]

sysctl -w net.netfilter.nf_conntrack_max=1048576

 

в /etc/modules

nf_conntrack hashsize=1048576

[DemYaN]

а в dmesg ничего аномального? например

ip_conntrack: table full, dropping packet

[Ivan Rostovikov]

блин....

Имено это там и есть:

 

[185866.307496] nf_conntrack: table full, dropping packet.

>sysctl -w net.netfilter.nf_conntrack_max=1048576

Это понимаю.

 

>в /etc/modules

>nf_conntrack hashsize=1048576

А это что ?

[2c2i]

размер хеша, меняет net.netfilter.nf_conntrack_buckets, должно быть примерно равно net.netfilter.nf_conntrack_count, можно опытным путем подобрать, если слишком малое число то поиск в таблице conntrack будет медленный.

[Nic]

ping: sendmsg: Operation not permitted

Переполнение арп-таблицы. лечить:

echo "8192" > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo "8192" > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo "8192" > /proc/sys/net/ipv4/neigh/default/gc_thresh3

вместо 8192 подобрать по вкусу

[disappointed]

блин....

Имено это там и есть:

Ну вот, с dmesg нужно было начинать искать

[2c2i]

Не думаю что на pppoe nas проблемы с размером арп таблицы.

[Ivan Rostovikov]

Действительно, арп не причем.

Переполнялась таблица conntrack.

Всем спасибо. Тему можно закрывать.