Автор Тема: Мрежова драма ...  (Прочетена 7358 пъти)

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Мрежова драма ...
« Отговор #15 -: Nov 28, 2012, 14:29 »
Здравей, от много голяма полза ще бъде ако покажеш изхода от следните команди:
netstat -s
и
ethtool -S <interface>
тази команда за всяка лан карта, която ползваш.
и
ethtool -k <interface>
За всяка карта (това не е чак толкова важно, просто за информация).
Интересно ще е да наблюдаваш чрез ethtool -S картата, където имаш проблем докато се случва и да
се опиташ да забележиш дали някой от *_errors броячите се променя много/често по време на проблема
(e.g. watch ethtool -S <interface> за всяка карта докато се случва проблема)
« Последна редакция: Nov 28, 2012, 14:32 от GytOS »
Активен

__asm__("jmp .");

ashandarey

  • Участници
  • ***
  • Публикации: 10
    • Профил
Re: Мрежова драма ...
« Отговор #16 -: Nov 28, 2012, 15:20 »
Здравей, от много голяма полза ще бъде ако покажеш изхода от следните команди:
netstat -s
и
ethtool -S <interface>
тази команда за всяка лан карта, която ползваш.
и
ethtool -k <interface>
За всяка карта (това не е чак толкова важно, просто за информация).
Интересно ще е да наблюдаваш чрез ethtool -S картата, където имаш проблем докато се случва и да
се опиташ да забележиш дали някой от *_errors броячите се променя много/често по време на проблема
(e.g. watch ethtool -S <interface> за всяка карта докато се случва проблема)

Малко дългичко ще се получи, но ето:

netstat -s
Ip:
    67181199 total packets received
    900 with invalid headers
    67037044 forwarded
    0 incoming packets discarded
    135622 incoming packets delivered
    67211518 requests sent out
    3 fragments dropped after timeout
    314 reassemblies required
    140 packets reassembled ok
    3 packet reassembles failed
    131 fragments received ok
    292 fragments created
Icmp:
    15264 ICMP messages received
    54 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 12
        timeout in transit: 2
        redirects: 58
        echo requests: 15192
    57301 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 41255
        time exceeded: 899
        echo replies: 15147
IcmpMsg:
        InType3: 12
        InType5: 58
        InType8: 15192
        InType11: 2
        OutType0: 15147
        OutType3: 41255
        OutType11: 899
Tcp:
    2 active connections openings
    1 passive connection openings
    0 failed connection attempts
    0 connection resets received
    3 connections established
119040 segments received
    117128 segments send out
    4 segments retransmited
    2 bad segments received.
    152 resets sent
Udp:
    39 packets received
    48 packets to unknown port received.
    0 packet receive errors
    41 packets sent
UdpLite:
TcpExt:
    241 delayed acks sent
    1 packets directly queued to recvmsg prequeue.
    1 bytes directly received in process context from prequeue
    104155 packet headers predicted
    6794 acknowledgments not containing data payload received
    3356 predicted acknowledgments
    1 times recovered from packet loss by selective acknowledgements
    1 fast retransmits
    3 other TCP timeouts
    TCPSackShiftFallback: 4
IpExt:
    InBcastPkts: 6015
    InOctets: 2011845164
    OutOctets: 1930710740
    InBcastOctets: 543260

ethtool -S eth0
NIC statistics:
     tx_packets: 5282621
     rx_packets: 6458224
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 6418033
     broadcast: 40088
     multicast: 103
     tx_aborted: 0
     tx_underrun: 0

ethtool -S eth1
NIC statistics:
     tx_bytes: 32520285154
     rx_bytes: 6209429201
     tx_broadcast: 14670
     rx_broadcast: 44994
     tx_multicast: 6
     rx_multicast: 1946
     tx_unicast: 28442628
     rx_unicast: 19060280
     tx_mac_pause: 0
     rx_mac_pause: 0
     collisions: 0
     multi_collisions: 0
     aborted: 0
     late_collision: 0
     fifo_underrun: 0
     fifo_overflow: 0
     rx_toolong: 0
     rx_jabber: 0
     rx_runt: 0
     rx_too_long: 0
     rx_fcs_error: 0

ethtool -S eth2
NIC statistics:
     tx_bytes: 5180782920
     rx_bytes: 417628143
     tx_broadcast: 22756
     rx_broadcast: 36919
     tx_multicast: 5
     rx_multicast: 0
     tx_unicast: 6345499
     rx_unicast: 2625099
     tx_mac_pause: 0
     rx_mac_pause: 0
     collisions: 0
     multi_collisions: 0
     aborted: 0
     late_collision: 0
     fifo_underrun: 0
     fifo_overflow: 0
     rx_toolong: 0
     rx_jabber: 0
     rx_runt: 0
     rx_too_long: 0
     rx_fcs_error: 0

ethtool -S eth3
NIC statistics:
     tx_bytes: 7894403786
     rx_bytes: 42625187712
     tx_broadcast: 28528
     rx_broadcast: 114408
     tx_multicast: 18
     rx_multicast: 0
     tx_unicast: 27414602
     rx_unicast: 39547012
     tx_mac_pause: 0
     rx_mac_pause: 0
     collisions: 0
     multi_collisions: 0
     aborted: 0
     late_collision: 0
     fifo_underrun: 0
     fifo_overflow: 390
     rx_toolong: 0
     rx_jabber: 0
     rx_runt: 0
     rx_too_long: 0
     rx_fcs_error: 0

ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

ethtool -k eth2
Offload parameters for eth2:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

ethtool -k eth3

Offload parameters for eth3:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

Наблюдавал съм с ethtool като я има драмата, сравнявал съм параметрите, няма разлика ...ако скоро стане, постоянно пингвам, ще постна същия изход от командите, когато я дава грешката, за съжаление нямам идея как да я предизвикам :)
Активен

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Мрежова драма ...
« Отговор #17 -: Nov 28, 2012, 15:49 »
Добре, тези карти имат доста малко броячи (това е между другото) :)
Има един полезен пакет, който се казва sysstat (оригинално може да бъде намерен тук: http://pagesperso-orange.fr/sebastien.godard/)
Разгледай инструментите, които предлага и най - вече виж mpstat (най - елементарния пример е mpstat 1 - което го кара да се ъпдейтва на всяка секунда за всички налични процесори).
Не видях назад дали някой е питал за натоварване на машината докато се случва проблема, но чрез този инструмент (а и другите в пакета) може да провериш.
Също така е важно да споделиш какъв трафик на карта/какъв трафик общо - докато се случва проблема.
И все пак, за да проверим параметрите би ли споделил следното:
lspci -vv
Само частта за лан картите (няма нужда от целия изход).
« Последна редакция: Nov 28, 2012, 16:03 от GytOS »
Активен

__asm__("jmp .");

ashandarey

  • Участници
  • ***
  • Публикации: 10
    • Профил
Re: Мрежова драма ...
« Отговор #18 -: Nov 28, 2012, 15:57 »
Добре, тези карти имат доста малко броячи (това е между другото) :)
Има един полезен пакет, който се казва sysstat (оригинално може да бъде намерен тук: http://pagesperso-orange.fr/sebastien.godard/)
Разгледай инструментите, които предлага и най - вече виж mpstat (най - елементарния пример е mpstat 1 - което го кара да се ъпдейтва на всяка секунда за всички налични процесори).
Не видях назад дали някой е питал за натоварване на машината докато се случва проблема, но чрез този инструмент (а и другите в пакета) може да провериш.

Дебиана си го има като пакетче в репа, инсталирах го оттам направо, пуснах го с mpstat 1 ....ако те интересува нещо конкретно от това което показва, ще постна ..виждам че си има папчица във /var/log ще видим и ще логне ли нещо :)
Активен

ashandarey

  • Участници
  • ***
  • Публикации: 10
    • Профил
Re: Мрежова драма ...
« Отговор #19 -: Nov 28, 2012, 16:19 »
Инсталриах sysstat на още две линукс машини, за да сравня резултатите, едната е мейл сървър другата е уеб сървър... В секцията irq и на двата други сървъра, се показват само нули, на проблемния сървър постоянно варират разни числа... Другото интересно е че при инсталацията на проблемния сървър изрева за missing firmware за realtek лан карти ...предните три лан карти бяха realtek, преди да ги сменя с 3com ... да не го сбозва това ....
Активен

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Мрежова драма ...
« Отговор #20 -: Nov 28, 2012, 16:56 »
Това за firmware-а няма общо.

Това са показатели за различен тип натоварване най - общо казано. Може да видиш повече информация в man mpstat
Запиши за 30тина (30 реда на mpstat 1) секунди тази информация докато се случва проблема, за да видим колко е натоварена машината по това време (докато се случва този проблем).
Отделно е много важно да запишеш колко е общия трафик докато се случва това (и още по добре на всяка карта по отделно - input & output).
Според мен (сега видях, че си писал, че картите ти са на PCI) проблема ти е в шината (заради повечето пакети/трафик). За това ти писах по горе да дадеш
lspci -vv изход за картите, но като цяло щом ползваш 3 карти по 1G (предполагам правиш над 100 mbps на карта, за да има нужда) на PCI рано или късно ще
имаш проблеми  :)
Добър инструмент за гледане на моментния трафик, който минава през машината (било то през 1 или през повече карти) е bmon (оригинално може да се намери на: http://www.infradead.org/~tgr/bmon/)
Горе видях, че са ти препоръчали също и cacti (то е повече за агрегиран вариант на тази информация), но също ще свърши работа за тази цел, освен ако нямаш някакви странни кратки пикове.
Инструмента си го избери, но е важно да видиш трафика, който минава докато се случва това и да се сметне дали тази шина (дори теоретично) може да издържи повече.
« Последна редакция: Nov 28, 2012, 17:01 от GytOS »
Активен

__asm__("jmp .");

ashandarey

  • Участници
  • ***
  • Публикации: 10
    • Профил
Re: Мрежова драма ...
« Отговор #21 -: Nov 28, 2012, 17:21 »
GytOS мерси много за вниманието и съветите, ако може да ви попитам за една идея ... IRQ конфликти ?
Извода на командата lspsi -v ми показва че SMBus VGA и Audio са на същите IRQта като лан картите съответно 16,17 и 18. Поразрових се и май ще се окаже това драмата ...Някаква идея как от самия линукс да променя IRQ-тата ? Или трябва да ровя в биоса ...Също така си го пише и в /proc/interrupts ....
Активен

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Мрежова драма ...
« Отговор #22 -: Nov 28, 2012, 17:42 »
Даден interrupt може да бъде споределн м/у няколко устройства, не е задължително да имаш "конфликти" :)
Не е лошо да са на отделни прекъсвания, може да си го оправиш от BIOS-а, въпреки че не мисля че това е проблема.
А звуковата карта ако не я ползваш направо я спри от BIOS-a/махни от слота.

Активен

__asm__("jmp .");

ashandarey

  • Участници
  • ***
  • Публикации: 10
    • Профил
Re: Мрежова драма ...
« Отговор #23 -: Nov 28, 2012, 18:08 »
Даден interrupt може да бъде споределн м/у няколко устройства, не е задължително да имаш "конфликти" :)
Не е лошо да са на отделни прекъсвания, може да си го оправиш от BIOS-а, въпреки че не мисля че това е проблема.
А звуковата карта ако не я ползваш направо я спри от BIOS-a/махни от слота.
мда ...саунда заминава първи :) Ще го видя това дъно как му е биоса ...че новите биоси са доста поорязани като опции ...всмисъл няма опция да зададеш IRQ на всеки отделен дивайс, ами мисля че има опция да кажеш операционната система да си ги задава, а не биоса ...и се надявам дебиана да ме зарадва още един път и да си направи бакийките както трябва :) Ще пиша каква съм я омазал, а иначе инсталирах cacti, следя с 5-6 инструмента всичко квот се случва ...за момента ...вече 3 дена стана е ок, ама както писах по рано имало е периоди от 20+ дена без драма, имало е периоди почти всеки ден ....
Активен

Acho

  • Напреднали
  • *****
  • Публикации: 5280
  • Distribution: Slackware, MikroTik - сървърно
  • Window Manager: console only
    • Профил
    • WWW
Re: Мрежова драма ...
« Отговор #24 -: Nov 28, 2012, 19:13 »
Ем те дивайсите повече от свободните прекъсвания.
Активен

CPU - Intel Quad-Core Q8400, 2.66 GHz; Fan - Intel Box; MB - Intel G41M-T2; RAM - DDR2-800, Kingston HyperX, 2X2048 MB; VC - onboard, Intel G41 Express Chipset; HDD - Toshiba, 500 GB, SATAII; SB - Realtek HD Audio; DVD-RW - TSSTcorp DVD-RW; LAN - Realtek PCI-E GBE Controller; PSU - Fortron 350 Watt.

netgraph

  • Напреднали
  • *****
  • Публикации: 34
  • Distribution: *BSD, Fedora, RHEL
  • Window Manager: Fluxbox, Mate
    • Профил
Re: Мрежова драма ...
« Отговор #25 -: Nov 29, 2012, 18:08 »
Ем те дивайсите повече от свободните прекъсвания.
Това не е вярно, според http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html има 224 user-defined прекъсвания в IA-32.
Сега колко от тях може да се използват всъщност е друг въпрос, но при всички положения ще има достатъчно за този случай.
(А ако мине на PCIe вече може да станат още много повече)

Цитат
The IA-32 Architecture defines 18 predefined interrupts and exceptions and 224 user defined interrupts, which are
associated with entries in the IDT.
Активен

__asm__("jmp .");