[Cramac]

Всем привет. Подскажите, есть сервер intel две встроенные сетевые

82574L/82578DM Gigabit Network Connection

на нем accel, ndsad, snmpd, шейпер htb из основных "грузильщиков"

 

# top

top - 21:19:55 up 12 days, 11:43, 1 user, load average: 0.12, 0.48, 1.52

Tasks: 162 total, 1 running, 161 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.3%us, 0.7%sy, 0.0%ni, 95.1%id, 0.0%wa, 0.0%hi, 3.9%si, 0.0%st

Cpu1 : 0.0%us, 0.3%sy, 0.0%ni, 97.2%id, 0.0%wa, 0.0%hi, 2.5%si, 0.0%st

Cpu2 : 0.7%us, 0.0%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 2.0%si, 0.0%st

Cpu3 : 0.3%us, 0.3%sy, 0.0%ni, 99.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu4 : 0.3%us, 0.3%sy, 0.0%ni, 93.8%id, 0.0%wa, 0.0%hi, 5.5%si, 0.0%st

Cpu5 : 0.3%us, 0.3%sy, 0.0%ni, 73.3%id, 0.0%wa, 0.0%hi, 26.1%si, 0.0%st

Cpu6 : 0.7%us, 0.7%sy, 0.0%ni, 64.7%id, 0.0%wa, 0.0%hi, 34.0%si, 0.0%st

Cpu7 : 0.0%us, 1.6%sy, 0.0%ni, 96.4%id, 1.6%wa, 0.0%hi, 0.3%si, 0.0%st

Mem: 4015620k total, 2828112k used, 1187508k free, 180800k buffers

Swap: 11747324k total, 324k used, 11747000k free, 1823736k cached

 

 

прерывания

 

 

правил в iptables >1600

 

пропускает в среднем 100-150мбит (нат), сессий 400-500

 

в последнее время стало много обрывов, в логах по этому поводу

[2012-03-25 21:14:07]: warn: ppp296: lcp: no echo reply

 

сегодня глобально всех сбросило с ошибкой:

debug: ppp193: fsm timeout

 

что такого происходит на сервере что так часто стало рвать?

 

netstat -s

Ip:

всего пакетов принято 239126200

481939 с неверными заголовками

5967 с неверными адресами

1303297733 перенаправлено

5 с неверным протоколом

0 входящих пакетов отклонено

входящих пакетов доставлено: 1703900678

запросов отправлено: 425034032

исходящих пакетов сброшено: 9636

фрагментов сброшено после тайм-аута: 645900

требуется повторных сборок: 2910596999

пакетов пересобрано удачно: 1427142351

пакетов пересобрано неудачно: 56106079

фрагментов получено удачно: 1370707200

фрагментов неудачно: 50946852

фрагментов создано: 2756001289

Icmp:

ICMP сообщений получено: 5658731

неудачных входящих ICMP сообщений: 615386

Гистограмма входа ICMP

пункт назначения недоступен: 569373

потери при прохождении: 50034

неверные параметры: 2

подавления от источника: 6863

перенаправления: 125543

эхо-запросы: 4853435

эхо-ответы: 15981

послано сообщений ICMP: 194621044

неудачные сообщения ICMP: 9207

Гистограмма выхода ICMP

пункт назначения недоступен: 189269521

время превышено: 490677

перенаправлений: 357

эхо-запросов: 16254

эхо-ответы: 4844235

IcmpMsg:

InType0: 15981

InType3: 569373

InType4: 6863

InType5: 125543

InType8: 4853435

InType11: 50034

InType12: 2

OutType0: 4844235

OutType3: 189269521

OutType5: 357

OutType8: 16254

OutType11: 490677

Tcp:

открытия активных соединений: 26648

открытия пассивных соединений: 255190

неудачные попытки соединения: 490403

получено сбросов соединений: 137496

соединений установлено: 425

сегментов получено: 166266801

отправлено сегментов: 162103551

повторно передано сегментов: 89471

плохих сегментов получено: 86139

сбросов послано: 149279608

Udp:

пакетов принято: 92106821

принято пакетов на неизвестный порт: 182374546

ошибок приема пакетов: 337502

пакетов послано: 168767858

UdpLite:

TcpExt:

получено неверных SYN cookies: 8525

получено сбросов для эмбриональных SYN_RECV сокетов: 490290

71028 TCP sockets finished time wait in fast timer

83 пакеты отброшены в установленных соединениях из-за временной метки

задержанных подтверждений послано: 154328

44 задержал подтверждение приема из-за заблокированного сокета

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

33759 times the listen queue of a socket overflowed

33759 SYNs to LISTEN sockets dropped

3037 packets directly queued to recvmsg prequeue.

460846 bytes directly in process context from backlog

3104506 bytes directly received in process context from prequeue

ожидаемых заголовков пакетов: 2012692

ожидаемых заголовков пакетов, непосредственно стоявших в очереди к пользователю: 2312

2145429 acknowledgments not containing data payload received

ожидаемые подтверждения: 4345639

30 times recovered from packet loss by selective acknowledgements

540 congestion windows recovered without slow start by DSACK

392 congestion windows recovered without slow start after partial ack

26 TCP data loss events

40 timeouts after reno fast retransmit

тайм-аутов после восстановления SACK: 631

77 timeouts in loss state

быстрых повторов передачи: 37

1 forward retransmits

255 retransmits in slow start

других TCP тайм-аутов: 43341

2970 DSACKs sent for old packets

1 DSACKs sent for out of order packets

получено DSACKs: 12942

16511 соединения сброшены из-за неожиданных данных

3990 connections reset due to early user close

разорванных соединений из-за тайм-аутов: 5094

TCPDSACKIgnoredOld: 11748

TCPDSACKIgnoredNoUndo: 321

TCPSackMerged: 96

TCPSackShiftFallback: 245

TCPDeferAcceptDrop: 20192

IpExt:

InTruncatedPkts: 1

InMcastPkts: 8590

InBcastPkts: 24288316

InOctets: 2029704172

OutOctets: -520764768

InMcastOctets: 240536

InBcastOctets: -445508110

[alexaaa]

Проверьте поддерживают эти сетевые igb драйвера, у вас прерываний толком нет, лучьше использовать igb сетевые 82576, проверьте настройки conntrack соединений, раньше использовал простой шейпер на tc, нагрузки больше 15% не было.

 

http://blog.peter.am/index.php/2010/11/09/big-traffic-linux

Изменено 25 марта, 2012 пользователем alexaaa

[Cramac]

с шейпером не то, tc шейпим.

 

sysctl -a | grep conntrack

net.netfilter.nf_conntrack_generic_timeout = 600

net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120

net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60

net.netfilter.nf_conntrack_tcp_timeout_established = 432000

net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120

net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30

net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120

net.netfilter.nf_conntrack_tcp_timeout_close = 10

net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300

net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300

error: permission denied on key 'net.ipv4.route.flush'

net.netfilter.nf_conntrack_tcp_loose = 1

net.netfilter.nf_conntrack_tcp_be_liberal = 0

net.netfilter.nf_conntrack_tcp_max_retrans = 3

net.netfilter.nf_conntrack_udp_timeout = 30

net.netfilter.nf_conntrack_udp_timeout_stream = 180

net.netfilter.nf_conntrack_icmp_timeout = 30

net.netfilter.nf_conntrack_acct = 1

net.netfilter.nf_conntrack_events = 1

net.netfilter.nf_conntrack_events_retry_timeout = 15

net.netfilter.nf_conntrack_max = 65536

net.netfilter.nf_conntrack_count = 51086

net.netfilter.nf_conntrack_buckets = 16384

net.netfilter.nf_conntrack_checksum = 1

net.netfilter.nf_conntrack_log_invalid = 0

net.netfilter.nf_conntrack_expect_max = 256

net.ipv4.netfilter.ip_conntrack_generic_timeout = 600

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000

net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30

net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300

net.ipv4.netfilter.ip_conntrack_tcp_loose = 1

net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0

net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3

net.ipv4.netfilter.ip_conntrack_udp_timeout = 30

net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180

net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30

net.ipv4.netfilter.ip_conntrack_max = 65536

net.ipv4.netfilter.ip_conntrack_count = 51089

net.ipv4.netfilter.ip_conntrack_buckets = 16384

net.ipv4.netfilter.ip_conntrack_checksum = 1

net.ipv4.netfilter.ip_conntrack_log_invalid = 0

error: permission denied on key 'net.ipv6.route.flush'

net.nf_conntrack_max = 65536

[alexaaa]

net.ipv4.ip_forward=1

net.ipv4.ip_dynaddr=1

net.ipv4.conf.default.rp_filter=1

net.core.rmem_max=16777216

net.core.wmem_max=16777216

net.ipv4.tcp_rmem=4096 87380 16777216

net.ipv4.tcp_wmem=4096 65536 16777216

net.ipv4.tcp_window_scaling=0

net.ipv4.tcp_timestamps=0

net.ipv4.tcp_sack=0

net.ipv4.tcp_syncookies=1

net.ipv4.tcp_synack_retries=1

net.ipv4.tcp_syn_retries=1

net.ipv4.tcp_fin_timeout=30

net.ipv4.tcp_keepalive_intvl=15

net.ipv4.tcp_keepalive_probes=5

net.ipv4.tcp_orphan_retries=1

net.ipv4.tcp_no_metrics_save=1

net.ipv4.tcp_moderate_rcvbuf=1

net.core.netdev_max_backlog=204800

net.core.somaxconn=262144

net.ipv4.neigh.default.gc_stale_time=240

net.ipv4.neigh.default.gc_thresh1=1280

net.ipv4.neigh.default.gc_thresh2=2048

net.ipv4.neigh.default.gc_thresh3=4096

net.netfilter.nf_conntrack_max=524288

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=14400

net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent=10

net.nf_conntrack_max=524288

[bos9]

net.ipv4.netfilter.ip_conntrack_max = 65536

net.ipv4.netfilter.ip_conntrack_count = 51089

 

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

[Cramac]

увеличил net.ipv4.netfilter.ip_conntrack_max в два раза, проблема осталась.

alexaaa а не поделитесь шаблоном/скриптом для какти для такого графика?

 

Сейчас net.ipv4.netfilter.ip_conntrack_count = 42418

вечером в пик, 50-55000

Изменено 26 марта, 2012 пользователем Cramac

[alexaaa]

увеличил net.ipv4.netfilter.ip_conntrack_max в два раза, проблема осталась.

alexaaa а не поделитесь шаблоном/скриптом для какти для такого графика?

 

Сейчас net.ipv4.netfilter.ip_conntrack_count = 42418

вечером в пик, 50-55000

в личку почту пишите скину

[lan-viper]

... а не поделитесь шаблоном/скриптом для какти для такого графика?

Conntrack Status(shows all connections on the linux-gateway)

[Cramac]

Спасибо, красивый график :)

но по сути проблемы, проблема пока есть, шаманство с conntrack не помогло

[alexaaa]

Спасибо, красивый график :)

но по сути проблемы, проблема пока есть, шаманство с conntrack не помогло

поменяйте сетевые, у вас совсем нераспределены прерывания по ядрам, вот ваш скриншот который вы скидывали,

Изменено 28 марта, 2012 пользователем alexaaa

[Cramac]

с другими сетевыми понятно, у них очередей больше, И как же должно быть распределены прерывания? сейчас все 4 от сетевух используют разные ядра.

 

Да и трафик у нас не такой уж большой...

Изменено 28 марта, 2012 пользователем Cramac

[alexaaa]

с другими сетевыми понятно, у них очередей больше, И как же должно быть распределены прерывания? сейчас все 4 от сетевух используют разные ядра.

 

Да и трафик у нас не такой уж большой...

дело не только в трафике, а в распределение нагрузки, если прерывания толком не распределены, а только например на пару ядер из 4-х, то эти ядра просто "засруться" и загрузка CPU вырастет, и все kernel panic.

Ещё есть важное правило mtu для vpn соединений

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

модуль ip_gre нужно удалить он конфликтует с асселем

на какой OS собран сервер?

Изменено 28 марта, 2012 пользователем alexaaa

[Cramac]

Linux ppp-server 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux

 

правила такого у нас нет в иптайблс. ip_gre не загружали даж.

[alexaaa]

Linux ppp-server 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux

 

правила такого у нас нет в иптайблс. ip_gre не загружали даж.

правило добавьте, ip_gre он по умолчанию подгружается, удалите его.

accel-ppp сами собираете из гита? или готовый пакет ставите? в Ubuntu могут библиотеки различаться с Debian, может чего то не хватает.

Изменено 29 марта, 2012 пользователем alexaaa

[Cramac]

нет, с accel проблемы нет, работает, не падает, собирал сам из гита. По конфигу accel мту 1400 правило так и забивать или уменьшать?

[Cramac]

что то странное творится с сервером. пинг до него ходит нормально но lcp пропадают, snmp не может достучатся до сервера. Соединения отваливаются все...

загрузка ЦПУ на нуле.

Неужто дело в сетевых стала? Стоит ли менять на Intel E1G42ET ?

есть еще подозрение на нетаповский ндсад....как его включаю, обязательно проблемы начинаются, без него, проблемы есть но малозаметные.... Онлайн в пике 410 ппп

 

Может стоит поставить лимит на коннекты с ИП?

Изменено 4 апреля, 2012 пользователем Cramac

[taf_321]

есть еще подозрение на нетаповский ндсад....как его включаю, обязательно проблемы начинаются, без него, проблемы есть но малозаметные.... Онлайн в пике 410 ппп

 

Я бы порекомендовал в качестве сенсора NetFlow более свежие и адекватные инструменты. ndsad заброшен разработчиками более 8 лет назад. Ну и снимать статистику через libpcap в современных условиях нонсенс.

[lan-viper]

Наиболее адекватный вариант - сенсор ipt_NETFLOW.

[breusovok]

ipt_netflow мне тоже нравится. В dmesg случайно нет записей про переполнение буфера? Я у себя систему достаточно долго тюнил, пока более менее вменяемо заработало.

[Jugernault]

Я дико извиняюсь, что не несколько не по теме - Вы rrd-шечку чем строили и визуализировали? Самописаное или публичное?

[lan-viper]

ipt_netflow мне тоже нравится. В dmesg случайно нет записей про переполнение буфера? Я у себя систему достаточно долго тюнил, пока более менее вменяемо заработало.

Нет, но у меня через сенсор проходит отностиельно небольшой поток в 100мбит.

 

Я дико извиняюсь, что не несколько не по теме - Вы rrd-шечку чем строили и визуализировали? Самописаное или публичное?

Это система мониторинга cacti, там всё уже автоматизировано.

Изменено 5 апреля, 2012 пользователем lan-viper

[Cramac]

Jugernault, как уже ответили, ссылка парой страниц ранее...

 

А кто нить ограничивает трафик от пользователей? на кол-во соединений от абонента?

Изменено 5 апреля, 2012 пользователем Cramac

[lan-viper]

Jugernault, как уже ответили, ссылка парой страниц ранее...

 

А кто нить ограничивает трафик от пользователей? на кол-во соединений от абонента?

И кол-во сессий и ппс ограничиваю

 

PS

Ребят, давайте для всего, что не касается accel-ppp напямую, создавать отдельные темы?

[Cramac]

а не поделитесь способом/правилами?

 

П.С.

надо попросить админа или модераторов разделить тему и вынести в отдельную тему что то типо "тюнинг сервера..."

 

П.С.С.

Что то после последних манипуляций стали замечать проблемы с ютубом. Ролики первые пару секунд грузится быстро, дальше начинает еле ползти...Что такое могло случится?

Изменено 7 апреля, 2012 пользователем Cramac

[andretty]

П.С.С.

Что то после последних манипуляций стали замечать проблемы с ютубом. Ролики первые пару секунд грузится быстро, дальше начинает еле ползти...Что такое могло случится?

Это не проблема, фича ютуба такая