Ivan Rostovikov Опубликовано 20 апреля, 2009 · Жалоба Перешел на Lenny. Собрал 2.6.29. Машина используется как PPPoE NAS. Примерно после 1000 соединений начинает спонтанно терять пакеты. Загрузка интерфейсов примерно 300Мб Общая загрузка ядер - не выше 3 %% Раньше стояло 2.6.26 и таких проблем небыло. Ядро собирал по умолчанию. Какие опции ядра показать ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 20 апреля, 2009 · Жалоба Общая загрузка ядер - не выше 3 %% в 3% все включено? и irq и softirq? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 апреля, 2009 (изменено) · Жалоба system+user+nice На 2.6.26 при прочих равных потерь небыло. Изменено 20 апреля, 2009 пользователем Ivan Rostovikov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2c2i Опубликовано 20 апреля, 2009 · Жалоба а netstat -i ошибки показывает на сетевухах? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 20 апреля, 2009 · Жалоба какой процент загрузки softirq (si) был на 2.6.26, а какой сейчас? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 апреля, 2009 · Жалоба >а 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, так же и сейчас. Субьективно, по ощущениям - машина совсем не загружена. С консоли пингуеш соседа по вилану - потери. С транзитными пакетами -тоже самое. :-( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 20 апреля, 2009 (изменено) · Жалоба в топе эти данные отображаются: 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% загрузки маловато Изменено 20 апреля, 2009 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 апреля, 2009 · Жалоба >просто для 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 20 апреля, 2009 · Жалоба ping: sendmsg: Operation not permittedcat /proc/sys/net/ipv4/netfilter/ip_conntrack_max? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 апреля, 2009 (изменено) · Жалоба # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max 65536 # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count 65536 Какой будет диагноз ? Изменено 20 апреля, 2009 пользователем Ivan Rostovikov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2c2i Опубликовано 20 апреля, 2009 · Жалоба sysctl -w net.netfilter.nf_conntrack_max=1048576 в /etc/modules nf_conntrack hashsize=1048576 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 20 апреля, 2009 · Жалоба а в dmesg ничего аномального? например ip_conntrack: table full, dropping packet Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 апреля, 2009 · Жалоба блин.... Имено это там и есть: [185866.307496] nf_conntrack: table full, dropping packet. >sysctl -w net.netfilter.nf_conntrack_max=1048576 Это понимаю. >в /etc/modules >nf_conntrack hashsize=1048576 А это что ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2c2i Опубликовано 20 апреля, 2009 · Жалоба размер хеша, меняет net.netfilter.nf_conntrack_buckets, должно быть примерно равно net.netfilter.nf_conntrack_count, можно опытным путем подобрать, если слишком малое число то поиск в таблице conntrack будет медленный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 20 апреля, 2009 · Жалоба 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 подобрать по вкусу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 20 апреля, 2009 · Жалоба блин....Имено это там и есть: Ну вот, с dmesg нужно было начинать искать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2c2i Опубликовано 20 апреля, 2009 · Жалоба Не думаю что на pppoe nas проблемы с размером арп таблицы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 21 апреля, 2009 · Жалоба Действительно, арп не причем. Переполнялась таблица conntrack. Всем спасибо. Тему можно закрывать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...