mrsaygo Опубликовано 2 июля, 2011 · Жалоба Пинг до шлюза неровный, от 1 до 40. Процессор не грузиться. На тазике - НАТ, бгп, статическая маршрутизация. 2.6.32-5-amd64 debian Вчера вечером картина была жестче - пинг до 400-700 , ksoftirqd ложил ядра в 100. Раньше такого не наблюдалось при том же ППС и том же трафике, посему подозреваю какую то заразу в сети. Прошу помощи в локализации данной проблемы. Есть подозрение на что-то с UDP (визуально при прыжке пинга растет к-ство UDP в tcpdump). Ip: 1579964473 total packets received 3716 with invalid headers 5222 with invalid addresses 1497266707 forwarded 1 with unknown protocol 0 incoming packets discarded 17817834 incoming packets delivered 1514774186 requests sent out 111480 outgoing packets dropped 44017 fragments dropped after timeout 116761986 reassemblies required 58089840 packets reassembled ok 583423 packet reassembles failed 2251 fragments received ok 22 fragments failed 5093 fragments created Icmp: 172011 ICMP messages received 51993 input ICMP message failed. ICMP input histogram: destination unreachable: 40594 timeout in transit: 2042 source quenches: 369 redirects: 1952 echo requests: 93439 echo replies: 23898 14301021 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 14050985 time exceeded: 254 redirect: 131947 echo request: 24463 echo replies: 93372 IcmpMsg: InType0: 23898 InType3: 40594 InType4: 369 InType5: 1952 InType8: 93439 InType11: 2042 OutType0: 93372 OutType3: 14050985 OutType5: 131947 OutType8: 24463 OutType11: 254 Tcp: 220 active connections openings 16198 passive connection openings 1 failed connection attempts 819 connection resets received 10 connections established 3450479 segments received 3310862 segments send out 1204 segments retransmited 6963 bad segments received. 3107235 resets sent Udp: 10303 packets received 13865006 packets to unknown port received. 1077 packet receive errors 5873 packets sent UdpLite: TcpExt: 131 invalid SYN cookies received 1 resets received for embryonic SYN_RECV sockets 22 ICMP packets dropped because they were out-of-window 10535 TCP sockets finished time wait in fast timer 2174 delayed acks sent 51 delayed acks further delayed because of locked socket Quick ack mode was activated 26 times 26594 packets directly queued to recvmsg prequeue. 63 bytes directly in process context from backlog 208094 bytes directly received in process context from prequeue 10862 packet headers predicted 8015 packets header predicted and directly queued to user 93078 acknowledgments not containing data payload received 31393 predicted acknowledgments 37 times recovered from packet loss due to fast retransmit 2 times recovered from packet loss by selective acknowledgements Detected reordering 3 times using time stamp 1 congestion windows fully recovered without slow start 40 congestion windows partially recovered using Hoe heuristic 5 congestion windows recovered without slow start by DSACK 12 timeouts after reno fast retransmit 11 timeouts in loss state 42 fast retransmits 34 retransmits in slow start 352 other TCP timeouts 8 classic Reno fast retransmits failed 20 DSACKs sent for old packets 16 DSACKs received 24 connections reset due to unexpected data 74 connections aborted due to timeout TCPDSACKIgnoredOld: 10 TCPSpuriousRTOs: 1 TCPSackShifted: 2 TCPSackMerged: 2 TCPSackShiftFallback: 9 IpExt: InTruncatedPkts: 162 InMcastPkts: 908 InBcastPkts: 325275 InOctets: -912123899 OutOctets: 637937344 InMcastOctets: 25424 InBcastOctets: 33884690 top - 10:56:32 up 16:01, 2 users, load average: 0.06, 0.07, 0.02 Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 0.4%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.1%hi, 4.8%si, 0.0%st Mem: 4055248k total, 377384k used, 3677864k free, 52640k buffers Swap: 3905528k total, 0k used, 3905528k free, 96980k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15892 root 20 0 10592 1364 1168 S 2 0.0 0:02.46 pps 16195 root 20 0 19060 1280 900 R 2 0.0 0:00.01 top 1 root 20 0 8352 804 668 S 0 0.0 0:01.61 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0 0.0 0:00.06 migration/0 4 root 20 0 0 0 0 S 0 0.0 2:51.38 ksoftirqd/0 5 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/0 6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1 7 root 20 0 0 0 0 S 0 0.0 2:42.95 ksoftirqd/1 8 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/1 9 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2 10 root 20 0 0 0 0 S 0 0.0 2:30.94 ksoftirqd/2 11 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/2 12 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3 13 root 20 0 0 0 0 S 0 0.0 2:23.73 ksoftirqd/3 14 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/3 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 (изменено) · Жалоба В общем ситуация не улучшилась(((( Периодически возникают скачки пинга(от нормальных 1 до 200-400). При чем пробовал ложить на 3828 (к которому подключен тазик) некоторые порты дабы определить источник. Результат - нормализация работы то при тушении порта №4 то при тушении порта №7 итд итп. Игрался с ethtool эффекта нет. Вот дополнительные сведения на всякий случай: root@gw:~# ethtool eth2 Settings for eth2: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: pumbag Wake-on: g Current message level: 0x00000001 (1) Link detected: yes root@gw:~# ethtool -g eth2 Ring parameters for eth2: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 1024 RX Mini: 0 RX Jumbo: 0 TX: 1024 Вот еще такого хватает Jul 3 08:27:10 gw kernel: [135117.309739] UDP: short packet: From 183.76.125.75:11975 0/28 to 91.193.168.166:12334 Jul 3 08:28:53 gw kernel: [135220.344230] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:28:56 gw kernel: [135223.348787] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:33:17 gw kernel: [135484.293850] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:49:46 gw kernel: [136473.240932] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:49:49 gw kernel: [136476.232174] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:51:14 gw kernel: [136561.246299] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:51:17 gw kernel: [136564.244619] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:53:01 gw kernel: [136667.983848] UDP: bad checksum. From 58.252.125.107:5273 to 91.193.168.166:5223 ulen 109 Jul 3 08:55:54 gw kernel: [136841.200762] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 08:55:57 gw kernel: [136844.195939] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 09:03:17 gw kernel: [137284.536871] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:03:29 gw kernel: [137295.840622] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:04:13 gw kernel: [137339.694785] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:04:38 gw kernel: [137364.622629] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:04:59 gw kernel: [137385.608127] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:05:17 gw kernel: [137403.887081] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:05:32 gw kernel: [137419.337552] UDP: bad checksum. From 81.30.188.72:55324 to 91.193.168.166:6001 ulen 1446 Jul 3 09:05:47 gw kernel: [137433.648951] UDP: bad checksum. From 81.30.184.131:16460 to 91.193.168.166:6001 ulen 1446 Jul 3 09:11:55 gw kernel: [137802.069051] UDP: short packet: From 83.204.110.171:256 65535/183 to 91.193.168.166:0 Jul 3 09:14:20 gw kernel: [137947.132392] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 Jul 3 09:14:23 gw kernel: [137950.137776] UDP: bad checksum. From 178.216.191.5:59513 to 91.193.160.228:2881 ulen 28 У кого какие идеи по этому поводу? В какую сторону еще посмотреть? Очень нужна помощь. Изменено 4 июля, 2011 пользователем mrsaygo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 4 июля, 2011 · Жалоба А чем могло помочь вырубание портов? Или тазик подключен к огромному L2-домену? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 · Жалоба На входе eth1, eth3 - Мир и Украина с вланов магистрала, крутится quagga bgp. На гиговый порт 3828 заходит eth2 тазика, с остальных портов (100-1000) подключены дома. На eth2 же натится трафик (для основного к-ства юзеров)+ пара алиасов для раздачи белых IP. На 3828 - traffic segmentation, то есть отдельные порты друг друга не видят, а видят только шлюз и днс. Тушение порта равнозначно ограничению трафика с портов. И вот какая штука, например пошел пинг порядка 50-100 делаю config ports 1-15 state disable сразу падает в 1 мс... делением вычисляю 1 порт, например 4.. все вроде хорошо, но потом ситуация сама собой нормализуется и таким же образом в следующий раз прихожу к выводу что виноват порт уже скажем 20, проблема плавающая, скачки пинга не постоянны и виноват каждый раз разный порт. Вот и не пойму на что грешить.. на флуд, свич или тазик... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба Покажите net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_buckets net.netfilter.nf_conntrack_checksum в момент проблемы и когда всё нормально работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 (изменено) · Жалоба Покажите net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_buckets net.netfilter.nf_conntrack_checksum в момент проблемы и когда всё нормально работает root@gw:~/gw# sysctl -a | grep net.netfilter.nf_conntrack net.netfilter.nf_conntrack_generic_timeout = 200 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 = 300 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 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 = 524280 error: permission denied on key 'net.ipv4.route.flush' net.netfilter.nf_conntrack_count = 45304 net.netfilter.nf_conntrack_buckets = 65536 net.netfilter.nf_conntrack_checksum = 1 net.netfilter.nf_conntrack_log_invalid = 0 net.netfilter.nf_conntrack_expect_max = 256 error: permission denied on key 'net.ipv6.route.flush' Кстати обратил внимание на error: permission denied on key 'net.ipv6.route.flush' в конце Это в момент когда все нормально, когда проблемы есть net.netfilter.nf_conntrack_count особо не растет, скачет около одного значения +/-, резкого роста не наблюдал Изменено 4 июля, 2011 пользователем mrsaygo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба dmesg | grep conntrack что-нибудь находится интересное? На сообщения про ipv6 просто не обращайте внимания Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 · Жалоба dmesg | grep conntrack что-нибудь находится интересное? На сообщения про ipv6 просто не обращайте внимания dmesg | grep conntrack - все чисто Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 (изменено) · Жалоба Из логов все что необычного вообще - martian source __ratelimit Redirect fromAdvised path это все на внешних интерфейсах но с величиной пинга на eth2 и выдачей tail -f корреляции не обнаружил((( Изменено 4 июля, 2011 пользователем mrsaygo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба Покажите ifconfig -a и cat /proc/interrupts Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 · Жалоба Как уже описал с распределением прерываний все в порядке CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 156 112 113 113 114 108 109 118 IO-APIC-edge timer 1: 1 0 2 1 1 1 1 1 IO-APIC-edge i8042 8: 0 1 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 0 0 1 1 1 1 IO-APIC-edge i8042 14: 11 10 12 12 10 11 8 10 IO-APIC-edge ata_piix 15: 0 0 0 0 0 0 0 0 IO-APIC-edge ata_piix 20: 19554 19882 19702 19761 19759 19682 19874 19740 IO-APIC-fasteoi ata_piix 22: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3, uhci_hcd:usb5 23: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4 25: 181159637 181051812 181145067 181014230 181031226 181110304 181030919 181095876 IO-APIC-fasteoi eth1 26: 15191 15216 18162 16623 18130 19081 15789 15632 IO-APIC-fasteoi 58: 204218133 204121512 204214535 204136614 204321416 204302974 204302075 204298195 PCI-MSI-edge eth3 59: 267542868 267746963 267557914 267768153 267564848 267503346 267586730 267525935 PCI-MSI-edge eth2 60: 0 0 1 0 2 1 0 0 PCI-MSI-edge ioat-msi NMI: 0 0 0 0 0 0 0 0 Non-maskable interrupts LOC: 194757460 175068268 166141850 155442378 146122640 141972183 140397154 138057451 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 0 0 0 0 Performance pending work RES: 894045 687201 555163 560395 820879 770095 719741 741387 Rescheduling interrupts CAL: 40808 21260 34539 23177 413 361 397 387 Function call interrupts TLB: 89531 95627 89107 90643 203029 191664 211340 199060 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 901 901 901 901 901 901 901 901 Machine check polls root@gw:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:07:e9:0a:ec:c0 inet addr:10.0.0.1 Bcast:10.0.255.255 Mask:255.255.0.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth1 Link encap:Ethernet HWaddr 00:07:e9:0a:f4:2c inet addr:UA-IX_IP Bcast:UA-IX_IP_broadcast Mask:255.255.255.252 inet6 addr: fe80::207:e9ff:fe0a:f42c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1730717448 errors:0 dropped:8966 overruns:0 frame:0 TX packets:1586460466 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:1410519939037 (1.2 TiB) TX bytes:1112125387080 (1.0 TiB) eth2 Link encap:Ethernet HWaddr 00:15:17:99:0c:51 inet addr:192.168.10.1 Bcast:192.168.255.255 Mask:255.255.0.0 inet6 addr: fe80::215:17ff:fe99:c51/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3563679544 errors:279 dropped:183675 overruns:0 frame:274 TX packets:4011312236 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2488556131837 (2.2 TiB) TX bytes:4205343215531 (3.8 TiB) Memory:b8800000-b8820000 eth2:0 Link encap:Ethernet HWaddr 00:15:17:99:0c:51 inet addr:real_ip0 Bcast:real_ip0_broadcast Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Memory:b8800000-b8820000 eth2:1 Link encap:Ethernet HWaddr 00:15:17:99:0c:51 inet addr:real_ip1 Bcast:real_ip1_broadcast Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Memory:b8800000-b8820000 eth2:2 Link encap:Ethernet HWaddr 00:15:17:99:0c:51 inet addr:real_ip2 Bcast:real_ip2_broadcast Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Memory:b8800000-b8820000 eth3 Link encap:Ethernet HWaddr 00:15:17:99:0c:50 inet addr:world_IP Bcast:world_IP_broadcast Mask:255.255.255.252 inet6 addr: fe80::215:17ff:fe99:c50/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2632700605 errors:0 dropped:260529 overruns:0 frame:0 TX packets:2026761498 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:2816252576613 (2.5 TiB) TX bytes:1377964971003 (1.2 TiB) Memory:b8820000-b8840000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6417 errors:0 dropped:0 overruns:0 frame:0 TX packets:6417 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1238415 (1.1 MiB) TX bytes:1238415 (1.1 MiB) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zaqwr Опубликовано 4 июля, 2011 · Жалоба Как уже описал с распределением прерываний все в порядке это не хорошо, прибейте прерывания от каждой сетевухи на разные ядра, скажем от eth0 на cpu0 , eth1 на cpu1 eth2 на cpu2, отключите hyper threading , а если уж раскладываете прерывания то поставьте карточку с бОльшим количеством очередей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 · Жалоба Как уже описал с распределением прерываний все в порядке это не хорошо, прибейте прерывания от каждой сетевухи на разные ядра, скажем от eth0 на cpu0 , eth1 на cpu1 eth2 на cpu2, отключите hyper threading , а если уж раскладываете прерывания то поставьте карточку с бОльшим количеством очередей. Хорошо, попробую, но раньше как бы с такими же настройками все работало хорошо. В общем совет уловил, с прерываниями думаю вы правы, хотя пожалуй причина не в них. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба Сколько правил в iptables? Нарисуйте ежеминутные графики dropped по eth2 и eth3 - есть корреляция с возрастаниями пингов? Если правил iptables мало, то остаётся лишь посоветовать пробовать более новые ядра, например, 2.6.35.последнее и 2.6.39.последнее. Под debian собирать ядра с kernel.org совсем не сложно, но можно и готовые пакеты найти. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба Как уже описал с распределением прерываний все в порядке это не хорошо, прибейте прерывания от каждой сетевухи на разные ядра, скажем от eth0 на cpu0 , eth1 на cpu1 eth2 на cpu2, отключите hyper threading , а если уж раскладываете прерывания то поставьте карточку с бОльшим количеством очередей. Хорошо, попробую, но раньше как бы с такими же настройками все работало хорошо. В общем совет уловил, с прерываниями думаю вы правы, хотя пожалуй причина не в них. Как раз из-за этого ksoftirqd может упираться в 100% cpu. А вот глюки, когда cpu не грузится в полку это уже другой вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 (изменено) · Жалоба Сколько правил в iptables? Нарисуйте ежеминутные графики dropped по eth2 и eth3 - есть корреляция с возрастаниями пингов? Если правил iptables мало, то остаётся лишь посоветовать пробовать более новые ядра, например, 2.6.35.последнее и 2.6.39.последнее. Под debian собирать ядра с kernel.org совсем не сложно, но можно и готовые пакеты найти. правил достаточно много, к тому же есть еще шейпер на htb. правил Iptables - около 1000 - в основном НАТ, но все же еще пару дней на всем том все работало... касательно дропов на eth2 они в точности равны ethtool -S eth2 rx_missed_errors: 183675 и в данный момент не растут(как и фрейм и еррорс), хотя пинг на 192,168,10,1 порядка 50 на остальных интерфейсам - по нулям а вот NIC statistics: rx_packets: 3643326741 tx_packets: 4101064932 rx_bytes: 2568840826202 tx_bytes: 4314582325670 rx_broadcast: 17152543 tx_broadcast: 1559115 rx_multicast: 256436 tx_multicast: 6 rx_errors: 281 tx_errors: 0 tx_dropped: 0 multicast: 256436 collisions: 0 rx_length_errors: 271 rx_over_errors: 0 rx_crc_errors: 5 rx_frame_errors: 0 rx_no_buffer_count: 2218584 rx_missed_errors: 183675 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 471644 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 11 tx_restart_queue: 9065319 rx_long_length_errors: 271 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 129418 tx_tcp_seg_failed: 0 rx_flow_control_xon: 53809928 rx_flow_control_xoff: 53810742 - растут по 1000 за секунду tx_flow_control_xon: 281271 tx_flow_control_xoff: 277201 rx_long_byte_count: 2568840826202 rx_csum_offload_good: 3503927226 rx_csum_offload_errors: 1893 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 16538199 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 остальное вроде в норме... куда еще взглянуть? Изменено 4 июля, 2011 пользователем mrsaygo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба Сколько правил в iptables? Нарисуйте ежеминутные графики dropped по eth2 и eth3 - есть корреляция с возрастаниями пингов? Если правил iptables мало, то остаётся лишь посоветовать пробовать более новые ядра, например, 2.6.35.последнее и 2.6.39.последнее. Под debian собирать ядра с kernel.org совсем не сложно, но можно и готовые пакеты найти. правил достаточно много, к тому же есть еще шейпер на htb. правил Iptables - около 1000 - в основном НАТ Зачем столько правил iptables для NAT? но все же еще пару дней на всем том все работало... При таком же кол-ве трансляций NAT? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 · Жалоба Сколько правил в iptables? Нарисуйте ежеминутные графики dropped по eth2 и eth3 - есть корреляция с возрастаниями пингов? Если правил iptables мало, то остаётся лишь посоветовать пробовать более новые ядра, например, 2.6.35.последнее и 2.6.39.последнее. Под debian собирать ядра с kernel.org совсем не сложно, но можно и готовые пакеты найти. правил достаточно много, к тому же есть еще шейпер на htb. правил Iptables - около 1000 - в основном НАТ Зачем столько правил iptables для NAT? но все же еще пару дней на всем том все работало... При таком же кол-ве трансляций NAT? Около 500 человек сидит за НАТом (маловато белых адресов к сожалению) НАТИТСЯ на 2 внешних интерфейса (через один мир через другой UA-IX) Да отлично жило все при таком же количестве трансляций. В топе идл на уровне 85-90% был (впрочем и сейчас так же) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба Судя по всем причина в том, что вы выделили жирным - rx_flow_control. http://forum.nag.ru/forum/index.php?showtopic=57284 но решения там нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mrsaygo Опубликовано 4 июля, 2011 (изменено) · Жалоба Судя по всем причина в том, что вы выделили жирным - rx_flow_control. http://forum.nag.ru/forum/index.php?showtopic=57284 но решения там нет ))) В закладках эта ссылка уж пару дней, жду и надеюсь вдруг ответят и оно! К стати интересная ситуация - на eth2 txqueuelen периодически сваливается в дефолтные 1000 ... как то сразу не обратил внимания. Восстановление 10000 не решает проблему, но почему оно слетает. Смысл в том что при тех же нагрузках все работало отлично. Наверное все же завтра найду чего то с ядром поновее и попробую так, пока грешу больше всего на тазик, может и железо, попробую пересобрать на другом, если ничего нового не придумается. И еще, кто подскажет что такое rx_smbus? Изменено 4 июля, 2011 пользователем mrsaygo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 4 июля, 2011 · Жалоба а как организована структура прохода по iptables? если есть пакеты котороые должно проходить больше 50-100 строк - то это может здорово тормозить всё. К тому-же было отмечено что при большой таблице contrack (торенты мать их за ногу) всё начинает дико тормозить. Порекомендовать в таких случаях можно 1. снизить число проходов по iptables для пакетов 2. отказаться от торентов :-) 3. разделить нагрузку на несколько машин 4. идеально - отказаться от НАТ ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 5 июля, 2011 · Жалоба И еще, кто подскажет что такое rx_smbus? E1000_STAT("rx_smbus", stats.mgprc) ... adapter->stats.mgprc += rd32(E1000_MGTPRC); ... #define E1000_MGTPRC 0x040B4 /* Management Packets RX Count - R/clr */ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...