Cramac Опубликовано 25 марта, 2012 · Жалоба Всем привет. Подскажите, есть сервер 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 25 марта, 2012 (изменено) · Жалоба Проверьте поддерживают эти сетевые igb драйвера, у вас прерываний толком нет, лучьше использовать igb сетевые 82576, проверьте настройки conntrack соединений, раньше использовал простой шейпер на tc, нагрузки больше 15% не было. http://blog.peter.am/index.php/2010/11/09/big-traffic-linux Изменено 25 марта, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 25 марта, 2012 · Жалоба с шейпером не то, 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 25 марта, 2012 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 26 марта, 2012 · Жалоба net.ipv4.netfilter.ip_conntrack_max = 65536 net.ipv4.netfilter.ip_conntrack_count = 51089 как то почти на грани... предположу, что временами и переполняется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 26 марта, 2012 (изменено) · Жалоба увеличил net.ipv4.netfilter.ip_conntrack_max в два раза, проблема осталась. alexaaa а не поделитесь шаблоном/скриптом для какти для такого графика? Сейчас net.ipv4.netfilter.ip_conntrack_count = 42418 вечером в пик, 50-55000 Изменено 26 марта, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 26 марта, 2012 · Жалоба увеличил net.ipv4.netfilter.ip_conntrack_max в два раза, проблема осталась. alexaaa а не поделитесь шаблоном/скриптом для какти для такого графика? Сейчас net.ipv4.netfilter.ip_conntrack_count = 42418 вечером в пик, 50-55000 в личку почту пишите скину Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 28 марта, 2012 · Жалоба ... а не поделитесь шаблоном/скриптом для какти для такого графика? Conntrack Status(shows all connections on the linux-gateway) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 28 марта, 2012 · Жалоба Спасибо, красивый график :) но по сути проблемы, проблема пока есть, шаманство с conntrack не помогло Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 28 марта, 2012 (изменено) · Жалоба Спасибо, красивый график :) но по сути проблемы, проблема пока есть, шаманство с conntrack не помогло поменяйте сетевые, у вас совсем нераспределены прерывания по ядрам, вот ваш скриншот который вы скидывали, Изменено 28 марта, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 28 марта, 2012 (изменено) · Жалоба с другими сетевыми понятно, у них очередей больше, И как же должно быть распределены прерывания? сейчас все 4 от сетевух используют разные ядра. Да и трафик у нас не такой уж большой... Изменено 28 марта, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 28 марта, 2012 (изменено) · Жалоба с другими сетевыми понятно, у них очередей больше, И как же должно быть распределены прерывания? сейчас все 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 29 марта, 2012 · Жалоба 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 не загружали даж. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 29 марта, 2012 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 29 марта, 2012 · Жалоба нет, с accel проблемы нет, работает, не падает, собирал сам из гита. По конфигу accel мту 1400 правило так и забивать или уменьшать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 апреля, 2012 (изменено) · Жалоба что то странное творится с сервером. пинг до него ходит нормально но lcp пропадают, snmp не может достучатся до сервера. Соединения отваливаются все... загрузка ЦПУ на нуле. Неужто дело в сетевых стала? Стоит ли менять на Intel E1G42ET ? есть еще подозрение на нетаповский ндсад....как его включаю, обязательно проблемы начинаются, без него, проблемы есть но малозаметные.... Онлайн в пике 410 ппп Может стоит поставить лимит на коннекты с ИП? Изменено 4 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 5 апреля, 2012 · Жалоба есть еще подозрение на нетаповский ндсад....как его включаю, обязательно проблемы начинаются, без него, проблемы есть но малозаметные.... Онлайн в пике 410 ппп Я бы порекомендовал в качестве сенсора NetFlow более свежие и адекватные инструменты. ndsad заброшен разработчиками более 8 лет назад. Ну и снимать статистику через libpcap в современных условиях нонсенс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 5 апреля, 2012 · Жалоба Наиболее адекватный вариант - сенсор ipt_NETFLOW. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
breusovok Опубликовано 5 апреля, 2012 · Жалоба ipt_netflow мне тоже нравится. В dmesg случайно нет записей про переполнение буфера? Я у себя систему достаточно долго тюнил, пока более менее вменяемо заработало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 5 апреля, 2012 · Жалоба Я дико извиняюсь, что не несколько не по теме - Вы rrd-шечку чем строили и визуализировали? Самописаное или публичное? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 5 апреля, 2012 (изменено) · Жалоба ipt_netflow мне тоже нравится. В dmesg случайно нет записей про переполнение буфера? Я у себя систему достаточно долго тюнил, пока более менее вменяемо заработало. Нет, но у меня через сенсор проходит отностиельно небольшой поток в 100мбит. Я дико извиняюсь, что не несколько не по теме - Вы rrd-шечку чем строили и визуализировали? Самописаное или публичное? Это система мониторинга cacti, там всё уже автоматизировано. Изменено 5 апреля, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 5 апреля, 2012 (изменено) · Жалоба Jugernault, как уже ответили, ссылка парой страниц ранее... А кто нить ограничивает трафик от пользователей? на кол-во соединений от абонента? Изменено 5 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 5 апреля, 2012 · Жалоба Jugernault, как уже ответили, ссылка парой страниц ранее... А кто нить ограничивает трафик от пользователей? на кол-во соединений от абонента? И кол-во сессий и ппс ограничиваю PS Ребят, давайте для всего, что не касается accel-ppp напямую, создавать отдельные темы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 5 апреля, 2012 (изменено) · Жалоба а не поделитесь способом/правилами? П.С. надо попросить админа или модераторов разделить тему и вынести в отдельную тему что то типо "тюнинг сервера..." П.С.С. Что то после последних манипуляций стали замечать проблемы с ютубом. Ролики первые пару секунд грузится быстро, дальше начинает еле ползти...Что такое могло случится? Изменено 7 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andretty Опубликовано 7 апреля, 2012 · Жалоба П.С.С. Что то после последних манипуляций стали замечать проблемы с ютубом. Ролики первые пару секунд грузится быстро, дальше начинает еле ползти...Что такое могло случится? Это не проблема, фича ютуба такая Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...