Покажи Публикации - ashandarey
* Виж публикациите на потр. | Виж темите на потр. | Виж прикачените файлове на потр
Страници: [1]
1  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 28, 2012, 18:08
Даден interrupt може да бъде споределн м/у няколко устройства, не е задължително да имаш "конфликти" :)
Не е лошо да са на отделни прекъсвания, може да си го оправиш от BIOS-а, въпреки че не мисля че това е проблема.
А звуковата карта ако не я ползваш направо я спри от BIOS-a/махни от слота.
мда ...саунда заминава първи :) Ще го видя това дъно как му е биоса ...че новите биоси са доста поорязани като опции ...всмисъл няма опция да зададеш IRQ на всеки отделен дивайс, ами мисля че има опция да кажеш операционната система да си ги задава, а не биоса ...и се надявам дебиана да ме зарадва още един път и да си направи бакийките както трябва :) Ще пиша каква съм я омазал, а иначе инсталирах cacti, следя с 5-6 инструмента всичко квот се случва ...за момента ...вече 3 дена стана е ок, ама както писах по рано имало е периоди от 20+ дена без драма, имало е периоди почти всеки ден ....
2  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 28, 2012, 17:21
GytOS мерси много за вниманието и съветите, ако може да ви попитам за една идея ... IRQ конфликти ?
Извода на командата lspsi -v ми показва че SMBus VGA и Audio са на същите IRQта като лан картите съответно 16,17 и 18. Поразрових се и май ще се окаже това драмата ...Някаква идея как от самия линукс да променя IRQ-тата ? Или трябва да ровя в биоса ...Също така си го пише и в /proc/interrupts ....
3  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 28, 2012, 16:19
Инсталриах sysstat на още две линукс машини, за да сравня резултатите, едната е мейл сървър другата е уеб сървър... В секцията irq и на двата други сървъра, се показват само нули, на проблемния сървър постоянно варират разни числа... Другото интересно е че при инсталацията на проблемния сървър изрева за missing firmware за realtek лан карти ...предните три лан карти бяха realtek, преди да ги сменя с 3com ... да не го сбозва това ....
4  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 28, 2012, 15:57
Добре, тези карти имат доста малко броячи (това е между другото) :)
Има един полезен пакет, който се казва sysstat (оригинално може да бъде намерен тук: http://pagesperso-orange.fr/sebastien.godard/)
Разгледай инструментите, които предлага и най - вече виж mpstat (най - елементарния пример е mpstat 1 - което го кара да се ъпдейтва на всяка секунда за всички налични процесори).
Не видях назад дали някой е питал за натоварване на машината докато се случва проблема, но чрез този инструмент (а и другите в пакета) може да провериш.

Дебиана си го има като пакетче в репа, инсталирах го оттам направо, пуснах го с mpstat 1 ....ако те интересува нещо конкретно от това което показва, ще постна ..виждам че си има папчица във /var/log ще видим и ще логне ли нещо :)
5  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: 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 като я има драмата, сравнявал съм параметрите, няма разлика ...ако скоро стане, постоянно пингвам, ще постна същия изход от командите, когато я дава грешката, за съжаление нямам идея как да я предизвикам :)
6  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 28, 2012, 13:52
Засякъл ли си някой да не те трови с много пакети (повече торенти)?
Това, към което мисля, че те насочва Йордан, е препълване на таблици на iptables, във връзка с контрола на трафика, но не съм специалист в това.

Защо не опиташ да вдигнеш лимита на кънекшъните на iptables ?

Имаш предвид в ip_conntrack_max да увелича числото предполагам ...в момента е 65536, ще го направя на 120000 примерно ...
7  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 27, 2012, 10:15
Мерси, прочетох темата, доколкото разбирам трябва да изпищи в syslog-a: kernel: ip_conntrack: table full, dropping packet или нещо подобно, аз нямам такива неща, прегледах логовете със задна дата също. Пичовете се притесняват и от ip_conntrack_max което в случая при тях е около 25000, при мен е близо 66000 :) Незнам дали е нормално. Но гледайки логовете нямам препълване на таблиците, освен ако може да се появи такова нещо без да се логне ?
8  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 27, 2012, 09:51
И аз не съм от най големите специалисти в TC, ако може да подскажете как мога да го засека това нещо ?
9  Хардуер за Линукс / Сървъри / Re: Мрежова драма ... -: Nov 27, 2012, 09:29
Здравейте пак и благодаря за отговорите. Гледах го с ethtool когато има и когато няма драма, разликата е нулева. Преди тези 3 3com-a бяха 3 риълтека на тяхно място и същия резултат ....поне 3com-ите се държат по дълго време. Дъното е Асус, предпочитам тази марка за дъна, а и в случая нямах голям избор, тъй като ми трябваха 3 PCI слота :) Драйверите, които слага са skge, които по принцип ползват Marvell lan cards, за 3com знам че са други 3c59x ако не се лъжа ? Но като напиша lspci излиза че са: Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 10) така че изключих драйвера да прави проблем, а и ако беше той щеше да не е на различни интервали, а по принцип да цака картите. Да и на трите лан карти се появява проблема ...Инсталирах и една програмка - mcelog която реве за хардуерни проблеми уж, логовете са празни от месец и нещо насам откакто е инсталирана ..
10  Хардуер за Линукс / Сървъри / Мрежова драма ... -: Nov 26, 2012, 09:44
Здравейте,
имам следния проблем, с който се боря от известно време и се рова из интернет, за съжаление не мога да намеря нищо подобно, като моето чудо ...
Проблема ми е следния:
Имам дебиански сървър, който е firewall и  shaper ...има 4 лан карти, една за входящ интернет и другите 3 са за три под мрежи. Три от лан картите са 3com, четвъртата е на дъното realtek. Всичко си бачка, без грешки без нищо ...но през определен интервал от време - 2 дена или 2 седмици ...винаги е различно, като напоследък зачести, пинга ми към потребителите в мрежата от usec става msec, което се отразява на тяхната интернет връзка. Няма нищо по логовете, което да ми подскаже какво би могло да бъде. Имам предположение, че е бъгаво дъното вече. Единственото, което помага е рестартиране на сървъра... Моля за съвет от някой или ако някой се е сблъксвал с нещо подобно ако може да сподели. Благодаря.
Страници: [1]