classic.ISPforum.cz

Zdravim,

zacaly se nam objevovat podivne problemy. Zrejme je zpusobuje "neco" na hranicni gatewayi. Hranicni GW dela NAT, routing a shaping pomoci HTB.

Pokud je zapnuty shaping pomoci HTB, tak dochazi obcas, vetsinou pres den odpoledne k jevu, kdy na siti behem 2-3 sekund poklesne provoz, pak se uplne zastavi a po cca 10-20 sekundach se provoz obnovi s tim, ze dojde ke kratkodobe spicce v navyseni provozu zhruba 3-4 krat. Tohle zpusobuje vypadky na cca 10-60 sekund (ale nekdy i na 3 minuty). Nejaky problem s buffery?

Pokud je HTB shaping na gatewayi vypnuty, zadne takove dlouhe vypadky se nekonaji, ale zase dochazi k podivnemu kolisani v prutoku siti. Rozdily mezi "zuby" grafu prutoku jsou cca 200Mbit/s, coz mi prijde moc na to, aby to byl normalni provoz zakazniku. Prikladam printscreen z routerboardu RB1100AHx2, ktery je zapojeny hned za GW smerem dovnitr site a je nastaveny jen jako bridge, na kterem konci VLANy (celkem 3 VLAN interface).

Gateway obsluhuje cca 2000 zakazniku. Popis HW serveru je taky v priloze. V serveru je sitova karta “SUPERMICRO Dual 1Gbe NIC, UIO, Low Profile Card“ podporujici rozdelovani IRQ sitoveho provozu na ruzna jadra CPU, vyuzivame vsech 16 queues. Verze IGB ovladace 5.0.6.

Na sitove karte eth1 (vnirtni) i eth0 (smerem do netu) jsem pokusne vypinal:
TCP Segmentation Offloading (TSO)
Generic Receive Offloading (GRO)
„generic-segmentation-offload
--> bez zadneho efektu na kolisavy provoz...

Zajimave treba je, ze porad narustaji errory „rx_fifo_errors“ , ktere sleduju prikazem „watch "ethtool -S eth1 | grep -i error"“. Errory narustaji rychlosti cca jednotek az desitek za zhruba 10 sekund. Toto jsem zatim sledoval jen pri vypnutem HTB.

Nesetkal jste se nekdo s necim podobnym?
Pep.

dalsi printscreeny

... a jeste pridam grafy ze stejneho routerboardu, kde je videt, jak se na provozu projevi problem pri zapnutem HTB. Udelalo to vypadek asi na 20 sekund. Tohle se opakuje po cca 5-6 minutach.

Pri zapnutem HTB zmizi ty divne zubate prenosy, ale zase objevuje toto...

P.

rx_fifo_error je IMHO nejaky problem sitove karty, ktera zrejme nema kam ulozit dalsi prijate packety. To by znamenalo, ze driver je z ni dostatecne rychle neuklada jinam.

podle internetu by na tom motherbpoardu mela byt sitovka s chipsetem 82576 coz je IMHO dostatecne solidni zalezitost. Pokud si s ni Tvuj linux kernel rozumi. Tahle sitovka umi rozkladat datovy tok na nekolik proudu a rozdelit jejich obsluhu na ruzne IRQ (tedy i CPU). Pokud nemas nejaky prehistoricky kernel (starsi nez 2.6.7), melo by to IMHO slapat samo (alesn nam to bezelo bez postrkovani).
Nejake Info jsem kdysi cerpal zde:
http://www.intel.com/content/www/us/en/ ... -note.html


taky bych se znail zjistit jestli server eni pretizeny obsluhou interruptu (irq i sofwarorovych)

... a jeste dalsi grafy, kde je videt okamzik, kdy se zacinaji do pameti cpat HTB pravidla. Dojde k vyrovnani grafu provozu, resp. prestane dochazet k padani rychlosti. Dokonceni reloadu vsech pravidel ale trva cca 20 minut, takze konec generovani HTB jeste v techto grafech neni.

to Dalibor Toman:
jj, na desce je vestavena karta "Intel® 82576 Dual-Port Gigabit Ethernet Controller", ktera je ale v BIOSu vypnuta. Pri nakupu serveru jsem totiz nepredpokladal, ze je onboard karta tak dobra, takze jsem rovnu koupil v podstate tu samou (Intel® 82576EB dual-port Gigabit Ethernet controller) a dal ji to PCI-E. Jinak to rozkladani IRQ na ruzna jadra funguje. Sice jsem to musel nastavit rucne, protoze irqbalanced prestal po upgrade z Debian Squeeze na Wheezy rozkladat IRQ na ruzna jadra, ale nacpal preruseni eth0 na jedno jadro a erh1 na druhe jadro. Tj. ted server bezi s kernelem 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux.
Softwarove interupty, tj. predpokladam ze proces ksoftirq se nezdaji byt problem, protoze tyto procesy se vubec neobjevuji ( a navic jejich objevovani a vytezovani CPU po zkusenostech ze starsiho HW serveru grafuju)
Pep.

PepeOnAchair píše:... a jeste dalsi grafy, kde je videt okamzik, kdy se zacinaji do pameti cpat HTB pravidla. Dojde k vyrovnani grafu provozu, resp. prestane dochazet k padani rychlosti. Dokonceni reloadu vsech pravidel ale trva cca 20 minut, takze konec generovani HTB jeste v techto grafech neni.

20 minut na reload HTB pravidel je nejak moc. Tim reloadem se mysli co? Mas vygenerovany file se spoustou radku typu 'tc class add .....' a ten pak 'spustis' ?
16000+ pravidel (qdisc, class, filter) nactu za mene nez 1 sekundu pomoci batch modu. Ciste sekvencne to trvalo driv 2-4 minuty

to vyhlazeni trva jen behem nacitani tech pravidel nebo i po nem? Sekvenci volani 'tc' je pro jadro docela zahul (neustale zamykani struktur u nas zpusobovolao lehkou ztratovost - drops)

to Dalibor Toman:
jj, na desce je vestavena karta "Intel® 82576 Dual-Port Gigabit Ethernet Controller", ktera je ale v BIOSu vypnuta. Pri nakupu serveru jsem totiz nepredpokladal, ze je onboard karta tak dobra, takze jsem rovnu koupil v podstate tu samou (Intel® 82576EB dual-port Gigabit Ethernet controller) a dal ji to PCI-E. Jinak to rozkladani IRQ na ruzna jadra funguje. Sice jsem to musel nastavit rucne, protoze irqbalanced prestal po upgrade z Debian Squeeze na Wheezy rozkladat IRQ na ruzna jadra, ale nacpal preruseni eth0 na jedno jadro a erh1 na druhe jadro. Tj. ted server bezi s kernelem 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux.
Softwarove interupty, tj. predpokladam ze proces ksoftirq se nezdaji byt problem, protoze tyto procesy se vubec neobjevuji ( a navic jejich objevovani a vytezovani CPU po zkusenostech ze starsiho HW serveru grafuju)
Pep.

jde spis o to, zda je opravdu pouzito vice IRQ vektoru na RX i TX z jedne sitovky: KOukam ted na jednu gateway, kterou tece take cca 300+mbps a je v ni stejny chipset na sitovkach. Mam tam pro kazdou sitovku jeden IRQ pro TX a 4 pro RX:

uryvek z /proc/interrupts:

CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
90: 24260 0 53257896 325970 52619422 640066 49156722 569055 PCI-MSI ahci
98: 1946 0 4074501844 397098140 1290572996 2379720244 94366659 3477140044 PCI-MSI-X eth0-tx-0
106: 24 0 3443103038 1446457517 3262663940 1537957321 3668523399 1033014921 PCI-MSI-X eth0-rx-0
114: 23 2803 3250353368 1469624836 3338590861 1642264020 3369154143 957002783 PCI-MSI-X eth0-rx-1
122: 407 0 3188197982 1342430475 3140173143 1667631129 3296177983 925756544 PCI-MSI-X eth0-rx-2
130: 26 440 3366614670 1423017179 3290008664 1727149678 3360003899 909593965 PCI-MSI-X eth0-rx-3
138: 0 0 0 0 0 0 0 0 PCI-MSI-X eth0
146: 9557 0 3336067242 1876460907 2805255587 2092896088 2954355637 1563464369 PCI-MSI-X eth1-tx-0
154: 7625 0 3571456481 1603368965 3186552308 1815139198 3534455308 1207926220 PCI-MSI-X eth1-rx-0
162: 5379 0 3473037166 1580928227 3248474493 1916685541 3440973966 1129786114 PCI-MSI-X eth1-rx-1
170: 5081 0 3289065176 1440136715 3197405418 1791457255 3384453924 1130063547 PCI-MSI-X eth1-rx-2
178: 4966 3848 3470218841 1709128645 3443711089 2055069772 3520315599 1206822984 PCI-MSI-X eth1-rx-3
186: 0 0 0 0 0 0 0 0 PCI-MSI-X eth1
LOC: 3630144224 3630144078 3630143068 3630143304 3630143170 3630143199 3630143072 3630143455

je tam podstatne starsi jadro nez mas ty (2.6.x - bezime na klonech RedHatu). A statistika od igb driveru neobsahuje zadne rx_fifo_errors (jen tx-fifo_errors)... Z offloading features mam zapnute jen ty co neslepuji packety (checksumming pro RX i TX)/ Zbytek ovlivnuje shapery - pak nebezi jak maji - data prekracuji nastavene rychlosti. Alespon na 2.6 jadrech (ackoliv zaplaty na to maji byt jiz v jadre. HTB proste nepocita s tim, ze packet bude vetsi nez 1500)

V tech 20 minutach se generuji tc a iptables pravidla. Neni to ale pro me problem, protoze cely shaper normalne od zacatku nespoustim, jen provadim rychle zmeny (taky v ramci sekund).

Vyhlazeni hragu trva i po kompletnim nahozeni HTB.

Jak zjistim, zda je opravdu pouzito vice IRQ vektoru na RX i TX z jedne sitovky? Doted jsem byl spokojenej, kdyz se navysovali citace IRQ v /proc/interrupts u kazde TX i RX queue sitove karty na vlastnim jardy CPU. Viz. video v priloze, pokud se mi ho povede odeslat.

PS: neni treba problem pouzivani hyperthreadingu?

Pep.

takze video je tady:
http://uloz.to/xHWTf2Ph/20140104-182934-xvid-avi

Pep.

PepeOnAchair píše:takze video je tady:
http://uloz.to/xHWTf2Ph/20140104-182934-xvid-avi

Pep.

ta sitovka je asi v poho. U nas jeste dochazi k obcasnemu stridani CPU na jednom IRQ (asi irqbalance

problem jeste muzes mi v iptaboes ci HTB. Jak moc to mas optimalizovany?
iptables
- pouzivas ipset nebo mas alespon ip rozsah nejak kasaovane rozsekanej pomoci subchainu - proste aby v nejhorsim pripade dochazelo k prolezani nejakeho rozumne maleho poctu pravidel
HTB
- pouzivas hash tabulky?

Pokud iptables nebo HTB pri velkem poctu pravidel nemas zoptimalizovany, tak bych se nedivil, ze to hapruje. Ale to by melo byt znat napr uz ve vypisu z top (prilis velke procento casu v 'si' (soft interrupts)

zapni si u toho htopu "Detailed CPU time" v nastavení htopu. Zapne to zobrazení všech ostatních zotížení v grafu.

Co to je? To neznám.

Dalibor Toman píše:16000+ pravidel (qdisc, class, filter) nactu za mene nez 1 sekundu pomoci batch modu. Ciste sekvencne to trvalo driv 2-4 minuty

ludvik píše:Co to je? To neznám.

Dalibor Toman píše:16000+ pravidel (qdisc, class, filter) nactu za mene nez 1 sekundu pomoci batch modu. Ciste sekvencne to trvalo driv 2-4 minuty

tc -b << file-pravidla.tc
v souboru uz mas prikazy do tc bez "tc" na zacatku tzn ad class .. atd

RAket píše:tc -b << file-pravidla.tc
v souboru uz mas prikazy do tc bez "tc" na zacatku tzn ad class .. atd

sipitko staci IMHO jedno. Kupodivu k tomuhle rezimu temer neexistuje dokumentace...

Ahoj, takze to vypada, ze se jednalo o masivni DDOS utoky, fuck...
Kazdopadne diky za tipy a snahu.
Pep.