Jump to content
Калькуляторы

Помогите определить проблему возрастание пинга при нормальной загрузке процессора

Пинг до шлюза неровный, от 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

Share this post


Link to post
Share on other sites

В общем ситуация не улучшилась(((( Периодически возникают скачки пинга(от нормальных 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

 

У кого какие идеи по этому поводу? В какую сторону еще посмотреть?

Очень нужна помощь.

Edited by mrsaygo

Share this post


Link to post
Share on other sites

А чем могло помочь вырубание портов? Или тазик подключен к огромному L2-домену?

Share this post


Link to post
Share on other sites

На входе 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, проблема плавающая, скачки пинга не постоянны и виноват каждый раз разный порт.

 

Вот и не пойму на что грешить.. на флуд, свич или тазик...

Share this post


Link to post
Share on other sites

Покажите

 

net.netfilter.nf_conntrack_max

net.netfilter.nf_conntrack_count

net.netfilter.nf_conntrack_buckets

net.netfilter.nf_conntrack_checksum

 

в момент проблемы и когда всё нормально работает

Share this post


Link to post
Share on other sites

Покажите

 

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 особо не растет, скачет около одного значения +/-, резкого роста не наблюдал

Edited by mrsaygo

Share this post


Link to post
Share on other sites

dmesg | grep conntrack что-нибудь находится интересное? На сообщения про ipv6 просто не обращайте внимания

Share this post


Link to post
Share on other sites

dmesg | grep conntrack что-нибудь находится интересное? На сообщения про ipv6 просто не обращайте внимания

dmesg | grep conntrack

- все чисто

Share this post


Link to post
Share on other sites

Из логов все что необычного вообще -

martian source

__ratelimit

Redirect fromAdvised path

 

это все на внешних интерфейсах

 

но с величиной пинга на eth2 и выдачей tail -f корреляции не обнаружил(((

Edited by mrsaygo

Share this post


Link to post
Share on other sites

Как уже описал с распределением прерываний все в порядке

 

           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)

Share this post


Link to post
Share on other sites
Как уже описал с распределением прерываний все в порядке

это не хорошо, прибейте прерывания от каждой сетевухи на разные ядра, скажем от eth0 на cpu0 , eth1 на cpu1 eth2 на cpu2, отключите hyper threading , а если уж раскладываете прерывания то поставьте карточку с бОльшим количеством очередей.

Share this post


Link to post
Share on other sites
Как уже описал с распределением прерываний все в порядке

это не хорошо, прибейте прерывания от каждой сетевухи на разные ядра, скажем от eth0 на cpu0 , eth1 на cpu1 eth2 на cpu2, отключите hyper threading , а если уж раскладываете прерывания то поставьте карточку с бОльшим количеством очередей.

 

Хорошо, попробую, но раньше как бы с такими же настройками все работало хорошо.

В общем совет уловил, с прерываниями думаю вы правы, хотя пожалуй причина не в них.

Share this post


Link to post
Share on other sites

Сколько правил в iptables?

Нарисуйте ежеминутные графики dropped по eth2 и eth3 - есть корреляция с возрастаниями пингов?

Если правил iptables мало, то остаётся лишь посоветовать пробовать более новые ядра, например, 2.6.35.последнее и 2.6.39.последнее. Под debian собирать ядра с kernel.org совсем не сложно, но можно и готовые пакеты найти.

Share this post


Link to post
Share on other sites
Как уже описал с распределением прерываний все в порядке

это не хорошо, прибейте прерывания от каждой сетевухи на разные ядра, скажем от eth0 на cpu0 , eth1 на cpu1 eth2 на cpu2, отключите hyper threading , а если уж раскладываете прерывания то поставьте карточку с бОльшим количеством очередей.

 

Хорошо, попробую, но раньше как бы с такими же настройками все работало хорошо.

В общем совет уловил, с прерываниями думаю вы правы, хотя пожалуй причина не в них.

 

Как раз из-за этого ksoftirqd может упираться в 100% cpu. А вот глюки, когда cpu не грузится в полку это уже другой вопрос.

Share this post


Link to post
Share on other sites

Сколько правил в 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

 

остальное вроде в норме... куда еще взглянуть?

Edited by mrsaygo

Share this post


Link to post
Share on other sites

Сколько правил в iptables?

Нарисуйте ежеминутные графики dropped по eth2 и eth3 - есть корреляция с возрастаниями пингов?

Если правил iptables мало, то остаётся лишь посоветовать пробовать более новые ядра, например, 2.6.35.последнее и 2.6.39.последнее. Под debian собирать ядра с kernel.org совсем не сложно, но можно и готовые пакеты найти.

 

правил достаточно много, к тому же есть еще шейпер на htb.

правил Iptables - около 1000 - в основном НАТ

 

Зачем столько правил iptables для NAT?

 

но все же еще пару дней на всем том все работало...

 

При таком же кол-ве трансляций NAT?

Share this post


Link to post
Share on other sites

Сколько правил в 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% был (впрочем и сейчас так же)

Share this post


Link to post
Share on other sites

Судя по всем причина в том, что вы выделили жирным - rx_flow_control. http://forum.nag.ru/forum/index.php?showtopic=57284 но решения там нет

 

))) В закладках эта ссылка уж пару дней, жду и надеюсь вдруг ответят и оно!

 

К стати интересная ситуация - на eth2 txqueuelen периодически сваливается в дефолтные 1000 ... как то сразу не обратил внимания.

Восстановление 10000 не решает проблему, но почему оно слетает. Смысл в том что при тех же нагрузках все работало отлично.

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

 

 

И еще, кто подскажет что такое rx_smbus?

Edited by mrsaygo

Share this post


Link to post
Share on other sites

а как организована структура прохода по iptables?

если есть пакеты котороые должно проходить больше 50-100 строк - то это может здорово тормозить всё.

К тому-же было отмечено что при большой таблице contrack (торенты мать их за ногу) всё начинает дико тормозить.

Порекомендовать в таких случаях можно

1. снизить число проходов по iptables для пакетов

2. отказаться от торентов :-)

3. разделить нагрузку на несколько машин

4. идеально - отказаться от НАТ ...

Share this post


Link to post
Share on other sites

И еще, кто подскажет что такое rx_smbus?

 

E1000_STAT("rx_smbus", stats.mgprc)
...
adapter->stats.mgprc += rd32(E1000_MGTPRC);
...
#define E1000_MGTPRC   0x040B4  /* Management Packets RX Count - R/clr */

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this