Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU 3050 @ 2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo obciazenie nie jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-) Dzieki!
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU 3050
@
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo obciazenie
nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-) Dzieki!
Zaraz sprawdzimy czy brakuje Ci CPU (choć nie powinno). Uruchom 'top', naciśnij "1" by wyświetlić statystyki per procesor i wklej wszystko u góry (bez listy procesów).
W dniu 5 września 2012 20:48 użytkownik Rafał Ramocki maniac@sistbg.netnapisał:
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU 3050
@
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo obciazenie
nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-) Dzieki!
Zaraz sprawdzimy czy brakuje Ci CPU (choć nie powinno). Uruchom 'top', naciśnij "1" by wyświetlić statystyki per procesor i wklej wszystko u góry (bez listy procesów).
top - 20:49:17 up 74 days, 17:59, 1 user, load average: 0.08, 0.12, 0.13 Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.4 us, 0.0 sy, 0.0 ni, 94.9 id, 0.0 wa, 0.0 hi, 4.7 si, 0.0 st %Cpu1 : 0.4 us, 0.4 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 5.2 si, 0.0 st Kb Mem: 8181488 total, 8058004 used, 123484 free, 283140 buffers Kb Swap: 2097148 total, 17568 used, 2079580 free, 7262712 cached
W dniu 05.09.2012 20:49, Sławomir Paszkiewicz napisał(a):
W dniu 5 września 2012 20:48 użytkownik Rafał Ramocki maniac@sistbg.net napisał:
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU
3050 @
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation
NetXtreme
BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo
obciazenie nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja
10-cio
krotnie.
Połączenia sieciowe do tych kart na pewno pracują na 1G?
W dniu 5 września 2012 20:52 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 05.09.2012 20:49, Sławomir Paszkiewicz napisał(a):
W dniu 5 września 2012 20:48 użytkownik Rafał Ramocki
maniac@sistbg.net napisał:
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz
paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU 3050
@
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo obciazenie
nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Połączenia sieciowe do tych kart na pewno pracują na 1G?
Tak:
# ethtool eth0|egrep -e "Speed|Duplex" && ethtool eth1|egrep -e "Speed|Duplex" Speed: 1000Mb/s Duplex: Full Speed: 1000Mb/s Duplex: Full
A pokaż jak wygląda /proc/interrupts Nam się przytykał przy ok 200Mbitach, zmieniliśmy karty na Intela, i sterownik na igb i teraz bez problemu robi ok. 500Mbitów. Problem był właśnie z przerywaniami.
© 2012
W dniu 5 września 2012 21:17 użytkownik Skiba Marek skibamarek@gmail.comnapisał:
A pokaż jak wygląda /proc/interrupts Nam się przytykał przy ok 200Mbitach, zmieniliśmy karty na Intela, i sterownik na igb i teraz bez problemu robi ok. 500Mbitów. Problem był właśnie z przerywaniami.
CPU0 CPU1
0: 21584 0 IO-APIC-edge timer 1: 8 0 IO-APIC-edge i8042 4: 11 0 IO-APIC-edge 6: 1 0 IO-APIC-edge 8: 7 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 14: 31 0 IO-APIC-edge ide0 16: 7 3185581076 IO-APIC-fasteoi eth0 17: 2096495027 0 IO-APIC-fasteoi eth1 20: 12910644 0 IO-APIC-fasteoi ata_piix, ehci_hcd:usb1, uhci_hcd:usb2 21: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 NMI: 584346 675604 Non-maskable interrupts LOC: 2653210516 484141642 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 584346 675604 Performance monitoring interrupts IWI: 0 0 IRQ work interrupts RTR: 0 0 APIC ICR read retries RES: 81873295 65819534 Rescheduling interrupts CAL: 1051 799 Function call interrupts TLB: 809067 731267 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 21535 21535 Machine check polls ERR: 0 MIS: 0
Wcześniej na IBM troche czytalem na temat wlasnie przerwan, zywalem irqbalance aby rozbic to na rozne rdzenie ale to pomagalo tylko chwilowo. Czytalem tez ze MSI na kartach moze pomoc, ale za nic nie udalo mi sie tego wlaczyc na sieciowkach.
W dniu 05.09.2012 21:22, Sławomir Paszkiewicz napisał(a):
W dniu 5 września 2012 21:17 użytkownik Skiba Marek skibamarek@gmail.com napisał:
A pokaż jak wygląda /proc/interrupts Nam się przytykał przy ok 200Mbitach, zmieniliśmy karty na Intela, i sterownik na igb i teraz bez problemu robi ok. 500Mbitów. Problem był właśnie z przerywaniami.
CPU0 CPU1 0: 21584 0 IO-APIC-edge timer 1: 8 0 IO-APIC-edge i8042 4: 11 0 IO-APIC-edge 6: 1 0 IO-APIC-edge 8: 7 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 14: 31 0 IO-APIC-edge ide0 16: 7 3185581076 IO-APIC-fasteoi eth0 17: 2096495027 0 IO-APIC-fasteoi eth1 20: 12910644 0 IO-APIC-fasteoi ata_piix, ehci_hcd:usb1, uhci_hcd:usb2 21: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 NMI: 584346 675604 Non-maskable interrupts LOC: 2653210516 484141642 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 584346 675604 Performance monitoring interrupts IWI: 0 0 IRQ work interrupts RTR: 0 0 APIC ICR read retries RES: 81873295 65819534 Rescheduling interrupts CAL: 1051 799 Function call interrupts TLB: 809067 731267 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 21535 21535 Machine check polls ERR: 0 MIS: 0
Wcześniej na IBM troche czytalem na temat wlasnie przerwan, zywalem irqbalance aby rozbic to na rozne rdzenie ale to pomagalo tylko chwilowo. Czytalem tez ze MSI na kartach moze pomoc, ale za nic nie udalo mi sie tego wlaczyc na sieciowkach.
Co pokazuje: dmesg |grep -i msi ? Możliwe, że Twoja płyta w serwerze źle obsługiwała przerwania przez MSI i w linuksie jest na sztywno wyłączone dla tej płyty korzystanie z MSI.
Wymiana sieciówek na przyzwoite intele 1G (nie muszą być ekstra serwerowe) i będzie ok.
On Wed, 5 Sep 2012 20:49:45 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
W dniu 5 września 2012 20:48 użytkownik Rafał Ramocki maniac@sistbg.netnapisał:
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU
3050
@
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo
obciazenie
nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-)
Dzieki!
Zaraz sprawdzimy czy brakuje Ci CPU (choć nie powinno). Uruchom 'top', naciśnij "1" by wyświetlić statystyki per procesor i wklej wszystko u góry (bez listy procesów).
top - 20:49:17 up 74 days, 17:59, 1 user, load average: 0.08, 0.12,
0.13
Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.4 us, 0.0 sy, 0.0 ni, 94.9 id, 0.0 wa, 0.0 hi, 4.7 si, 0.0 st %Cpu1 : 0.4 us, 0.4 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 5.2 si, 0.0 st Kb Mem: 8181488 total, 8058004 used, 123484 free, 283140 buffers Kb Swap: 2097148 total, 17568 used, 2079580 free, 7262712 cached
Maszyna się nudzi i dłubie palcem w nosie. Problemem nie jest zbyt rozbudowany FW (%si by było wyżej), nie są przerwania sprzętowe na sieciówkach (%hi by było wyżej), nie kończy Ci się pamięć (w cache jest 7G). Czy na pewno to ten serwer jest Twoim wąskim gardłem? Może pomiędzy nim, a siecią masz jeszcze "coś". Może problem leży u dostawcy?
Masz jakieś cacti (lub inny wykres) pokazujący pps i bps na interfejsach? Czy tam podczas spadku prędkości dla klienta widać spadek w ilości pps i/lub bps?
W dniu 5 września 2012 21:44 użytkownik Rafał Ramocki maniac@sistbg.netnapisał:
On Wed, 5 Sep 2012 20:49:45 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
W dniu 5 września 2012 20:48 użytkownik Rafał Ramocki maniac@sistbg.netnapisał:
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU
3050
@
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo
obciazenie
nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-)
Dzieki!
Zaraz sprawdzimy czy brakuje Ci CPU (choć nie powinno). Uruchom 'top', naciśnij "1" by wyświetlić statystyki per procesor i wklej wszystko u góry (bez listy procesów).
top - 20:49:17 up 74 days, 17:59, 1 user, load average: 0.08, 0.12,
0.13
Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.4 us, 0.0 sy, 0.0 ni, 94.9 id, 0.0 wa, 0.0 hi, 4.7 si, 0.0 st %Cpu1 : 0.4 us, 0.4 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 5.2 si, 0.0 st Kb Mem: 8181488 total, 8058004 used, 123484 free, 283140 buffers Kb Swap: 2097148 total, 17568 used, 2079580 free, 7262712 cached
Maszyna się nudzi i dłubie palcem w nosie. Problemem nie jest zbyt rozbudowany FW (%si by było wyżej), nie są przerwania sprzętowe na sieciówkach (%hi by było wyżej), nie kończy Ci się pamięć (w cache jest 7G). Czy na pewno to ten serwer jest Twoim wąskim gardłem? Może pomiędzy nim, a siecią masz jeszcze "coś". Może problem leży u dostawcy?
Masz jakieś cacti (lub inny wykres) pokazujący pps i bps na interfejsach? Czy tam podczas spadku prędkości dla klienta widać spadek w ilości pps i/lub bps?
-- z poważaniem Rafał Ramocki _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Nie no musisz rozłożyć przerwania żeby jedna karta na jednym cpu chodziła.
Kurde nie zauważyłem, ze jest tak. To jest częsty problem, że przerwania się nie wyrabiają.
PK
W dniu 5 września 2012 22:25 użytkownik Piotr Kaczor <kaczor.piotr@gmail.com
napisał:
W dniu 5 września 2012 21:44 użytkownik Rafał Ramocki maniac@sistbg.netnapisał:
On Wed, 5 Sep 2012 20:49:45 +0200, Sławomir Paszkiewicz
paszczus@gmail.com wrote:
W dniu 5 września 2012 20:48 użytkownik Rafał Ramocki maniac@sistbg.netnapisał:
On Wed, 5 Sep 2012 20:44:54 +0200, Sławomir Paszkiewicz paszczus@gmail.com wrote:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU
3050
@
2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo
obciazenie
nie
jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-)
Dzieki!
Zaraz sprawdzimy czy brakuje Ci CPU (choć nie powinno). Uruchom 'top', naciśnij "1" by wyświetlić statystyki per procesor i wklej wszystko u góry (bez listy procesów).
top - 20:49:17 up 74 days, 17:59, 1 user, load average: 0.08, 0.12,
0.13
Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.4 us, 0.0 sy, 0.0 ni, 94.9 id, 0.0 wa, 0.0 hi, 4.7 si, 0.0 st %Cpu1 : 0.4 us, 0.4 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 5.2 si, 0.0 st Kb Mem: 8181488 total, 8058004 used, 123484 free, 283140 buffers Kb Swap: 2097148 total, 17568 used, 2079580 free, 7262712 cached
Maszyna się nudzi i dłubie palcem w nosie. Problemem nie jest zbyt rozbudowany FW (%si by było wyżej), nie są przerwania sprzętowe na sieciówkach (%hi by było wyżej), nie kończy Ci się pamięć (w cache jest 7G). Czy na pewno to ten serwer jest Twoim wąskim gardłem? Może pomiędzy nim, a siecią masz jeszcze "coś". Może problem leży u dostawcy?
Masz jakieś cacti (lub inny wykres) pokazujący pps i bps na interfejsach? Czy tam podczas spadku prędkości dla klienta widać spadek w ilości pps i/lub bps?
-- z poważaniem Rafał Ramocki _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Nie no musisz rozłożyć przerwania żeby jedna karta na jednym cpu chodziła.
--
Ze sportowym pozdrowieniem ;-)
Wiadomość napisana przez Piotr Kaczor w dniu 5 wrz 2012, o godz. 22:26:
Kurde nie zauważyłem, ze jest tak. To jest częsty problem, że przerwania się nie wyrabiają.
PK
Na nowych plytach serwerowych intela z pci-e nie ma to juz takiego znaczenia. U nas kiedys na boradcomach powyzej 20k pps juz mielismy bledy na interfejsach.
Intele serwerowe PT lub lepiej ET to najlepsze karty na router linuxowy GE. Pozdrawiam.
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
W dniu 2012-09-05 23:45, joynet@vp.pl pisze:
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
-- Wysłane z Androida za pomocą K-9 Mail. Prosze wybaczyć lakoniczność.
"Łukasz Matys" lukasz@e-matys.com napisał:
Wiadomość napisana przez Piotr Kaczor w dniu 5 wrz 2012, o godz. 22:26: > Kurde nie zauważyłem, ze jest tak. To jest częsty problem, że przerwania się nie wyrabiają. > > PK Na nowych plytach serwerowych intela z pci-e nie ma to juz takiego znaczenia. U nas kiedys na boradcomach powyzej 20k pps juz mielismy bledy na interfejsach. Intele serwerowe PT lub lepiej ET to najlepsze karty na router linuxowy GE. Pozdrawiam. -- Matys Łukasz mobile: (+ 48) 504257944 ------------------------------------------------------------------------ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
On Thu, 06 Sep 2012 06:44:21 +0200, Łukasz Czerepuk lukasz@jpk.pl wrote:
Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt
wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB
szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
Czy ktoś ma jakieś dane lub wykresy pokazujące, że na routerze z dwoma sieciówkami przerzucającym ruch pomiędzy jedną poprawia wydajność? Sam nie miałem takich problemów i nigdy tego nie robiłem (zgodnie z zasadą jak działa to nie naprawiaj), chociaż kiedyś kiedyś lata temu się nad tym zastanawiałem. Trafiłem wtedy na ostrzeżenie, że ustawienie dwóch kart na różnych przerwaniach na routerze doprowadzi do tego, że wątek odpowiedzialny za przeprocesowanie pakietu na pewnym etapie będzie musiał być przerzucony z jednego CPU na drugi, co będzie skutkowało unieważnieniem cache CPU, a to z kolei może doprowadzić do obniżenia wydajności.
Więc czy ktoś może się pochwalić wykresem pokazującym, że w sytuacji ISP to pomaga?
28: 1144838359 1141578850 1142555890 1142199220 PCI-MSI-edge eth0 30: 725987516 729320616 728264140 728719922 PCI-MSI-edge eth2 Mam dwie sieciowki, przerzucajace ruch pomiedzy soba i nigdy nie zauwazylem spadku wydajnosci. Ruch jest na poziomie w szczycie ~230-240Mbps.
W dniu 2012-09-06 07:59, Rafał Ramocki pisze:
On Thu, 06 Sep 2012 06:44:21 +0200, Łukasz Czerepuk lukasz@jpk.pl wrote:
Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
Czy ktoś ma jakieś dane lub wykresy pokazujące, że na routerze z dwoma sieciówkami przerzucającym ruch pomiędzy jedną poprawia wydajność? Sam nie miałem takich problemów i nigdy tego nie robiłem (zgodnie z zasadą jak działa to nie naprawiaj), chociaż kiedyś kiedyś lata temu się nad tym zastanawiałem. Trafiłem wtedy na ostrzeżenie, że ustawienie dwóch kart na różnych przerwaniach na routerze doprowadzi do tego, że wątek odpowiedzialny za przeprocesowanie pakietu na pewnym etapie będzie musiał być przerzucony z jednego CPU na drugi, co będzie skutkowało unieważnieniem cache CPU, a to z kolei może doprowadzić do obniżenia wydajności.
Więc czy ktoś może się pochwalić wykresem pokazującym, że w sytuacji ISP to pomaga?
Pytanie czy zaobserwowales wzrost gdy to zrobiles?
Pozdrawiam
Dnia 6 wrz 2012 o godz. 08:18 Łukasz Czerepuk lukasz@jpk.pl napisał(a):
28: 1144838359 1141578850 1142555890 1142199220 PCI-MSI-edge eth0 30: 725987516 729320616 728264140 728719922 PCI-MSI-edge eth2 Mam dwie sieciowki, przerzucajace ruch pomiedzy soba i nigdy nie zauwazylem spadku wydajnosci. Ruch jest na poziomie w szczycie ~230-240Mbps.
W dniu 2012-09-06 07:59, Rafał Ramocki pisze:
On Thu, 06 Sep 2012 06:44:21 +0200, Łukasz Czerepuk lukasz@jpk.pl wrote:
Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
Czy ktoś ma jakieś dane lub wykresy pokazujące, że na routerze z dwoma sieciówkami przerzucającym ruch pomiędzy jedną poprawia wydajność? Sam nie miałem takich problemów i nigdy tego nie robiłem (zgodnie z zasadą jak działa to nie naprawiaj), chociaż kiedyś kiedyś lata temu się nad tym zastanawiałem. Trafiłem wtedy na ostrzeżenie, że ustawienie dwóch kart na różnych przerwaniach na routerze doprowadzi do tego, że wątek odpowiedzialny za przeprocesowanie pakietu na pewnym etapie będzie musiał być przerzucony z jednego CPU na drugi, co będzie skutkowało unieważnieniem cache CPU, a to z kolei może doprowadzić do obniżenia wydajności.
Więc czy ktoś może się pochwalić wykresem pokazującym, że w sytuacji ISP to pomaga?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 06.09.2012 06:44, Łukasz Czerepuk pisze:
Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
W dniu 2012-09-05 23:45, joynet@vp.pl pisze:
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
Jesli chodzi o ipset to wszystkie reguly ktore wczesniej obslugiwane byly poprzez iptables czyli kazdy komputer to byla jedna linijka w iptables. Teraz jest na kazda podsiec (podsieci jest 23) to osobny ipset a wiec linijek dla iptables / nat jest 23. Do tego jest troche w tabeli nat dla publicznych IP i tyle. Ogolnie duzo tego nie ma:
# iptables -t nat -L -nv|wc -l 116
# iptables -L FORWARD -nv|wc -l 36
Rzeczywiscie najwiekszym problemem moze byc HTB:
# tc qdisc show qdisc htb 1: dev eth0 root refcnt 6 r2q 10 default 0 direct_packets_stat 3072877145 qdisc htb 1: dev eth1 root refcnt 6 r2q 10 default 0 direct_packets_stat 459710 qdisc htb 1: dev imq0 root refcnt 3 r2q 10 default 0 direct_packets_stat 933285
# tc class show dev eth1|wc -l 352
# tc class show dev imq0|wc -l 352
Wlaczylem jeszcze irqbalanace. Zobaczymy czy cos sie zmieni.
W dniu 06.09.2012 06:44, Łukasz Czerepuk pisze: Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
W dniu 2012-09-05 23:45, joynet@vp.pl pisze:
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
Jesli chodzi o ipset to wszystkie reguly ktore wczesniej obslugiwane byly poprzez iptables czyli kazdy komputer to byla jedna linijka w iptables. Teraz jest na kazda podsiec (podsieci jest 23) to osobny ipset a wiec linijek dla iptables / nat jest 23. Do tego jest troche w tabeli nat dla publicznych IP i tyle. Ogolnie duzo tego nie ma:
# iptables -t nat -L -nv|wc -l 116
# iptables -L FORWARD -nv|wc -l 36
Rzeczywiscie najwiekszym problemem moze byc HTB:
# tc qdisc show qdisc htb 1: dev eth0 root refcnt 6 r2q 10 default 0 direct_packets_stat 3072877145 qdisc htb 1: dev eth1 root refcnt 6 r2q 10 default 0 direct_packets_stat 459710 qdisc htb 1: dev imq0 root refcnt 3 r2q 10 default 0 direct_packets_stat 933285
# tc class show dev eth1|wc -l 352
# tc class show dev imq0|wc -l 352
Wlaczylem jeszcze irqbalanace. Zobaczymy czy cos sie zmieni. _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
irq balance niczego nie zmieni, masz do bani podzial pasma polecam przy tylu klasach sieciowych zastosowac filtry mieszajace, dzialaja super
W dniu 06.09.2012 11:07, JOYNET napisał(a):
W dniu 06.09.2012 06:44, Łukasz Czerepuk pisze: Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
W dniu 2012-09-05 23:45, joynet@vp.pl pisze:
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
Jesli chodzi o ipset to wszystkie reguly ktore wczesniej obslugiwane byly poprzez iptables czyli kazdy komputer to byla jedna linijka w iptables. Teraz jest na kazda podsiec (podsieci jest 23) to osobny ipset a wiec linijek dla iptables / nat jest 23. Do tego jest troche w tabeli nat dla publicznych IP i tyle. Ogolnie duzo tego nie ma:
# iptables -t nat -L -nv|wc -l 116
# iptables -L FORWARD -nv|wc -l 36
Rzeczywiscie najwiekszym problemem moze byc HTB:
# tc qdisc show qdisc htb 1: dev eth0 root refcnt 6 r2q 10 default 0 direct_packets_stat 3072877145 qdisc htb 1: dev eth1 root refcnt 6 r2q 10 default 0 direct_packets_stat 459710 qdisc htb 1: dev imq0 root refcnt 3 r2q 10 default 0 direct_packets_stat 933285
# tc class show dev eth1|wc -l 352
# tc class show dev imq0|wc -l 352
Wlaczylem jeszcze irqbalanace. Zobaczymy czy cos sie zmieni.
irq balance niczego nie zmieni, masz do bani podzial pasma polecam przy tylu klasach sieciowych zastosowac filtry mieszajace, dzialaja super
Klasy już zobaczyliśmy, tabelę nat i trochę filter również, ale filtrów tc, ani tabeli mangle jeszcze nie ;-) Co tam takiego tajnego ukrywasz Sławku? ;-)
W dniu 06.09.2012 11:51, Tomasz Chiliński pisze:
W dniu 06.09.2012 11:07, JOYNET napisał(a):
W dniu 06.09.2012 06:44, Łukasz Czerepuk pisze: Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
W dniu 2012-09-05 23:45, joynet@vp.pl pisze:
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
Jesli chodzi o ipset to wszystkie reguly ktore wczesniej obslugiwane byly poprzez iptables czyli kazdy komputer to byla jedna linijka w iptables. Teraz jest na kazda podsiec (podsieci jest 23) to osobny ipset a wiec linijek dla iptables / nat jest 23. Do tego jest troche w tabeli nat dla publicznych IP i tyle. Ogolnie duzo tego nie ma:
# iptables -t nat -L -nv|wc -l 116
# iptables -L FORWARD -nv|wc -l 36
Rzeczywiscie najwiekszym problemem moze byc HTB:
# tc qdisc show qdisc htb 1: dev eth0 root refcnt 6 r2q 10 default 0 direct_packets_stat 3072877145 qdisc htb 1: dev eth1 root refcnt 6 r2q 10 default 0 direct_packets_stat 459710 qdisc htb 1: dev imq0 root refcnt 3 r2q 10 default 0 direct_packets_stat 933285
# tc class show dev eth1|wc -l 352
# tc class show dev imq0|wc -l 352
Wlaczylem jeszcze irqbalanace. Zobaczymy czy cos sie zmieni.
irq balance niczego nie zmieni, masz do bani podzial pasma polecam przy tylu klasach sieciowych zastosowac filtry mieszajace, dzialaja super
Klasy już zobaczyliśmy, tabelę nat i trochę filter również, ale filtrów tc, ani tabeli mangle jeszcze nie ;-) Co tam takiego tajnego ukrywasz Sławku? ;-)
Nic tajnego, myslalem ze to malo znaczace ;-)
# tc filter show dev eth1|wc -l 1848
tc filter show dev imq0|wc -l 1848
No i kawalek dla eth1:
filter parent 1: protocol ip pref 48691 u32 filter parent 1: protocol ip pref 48691 u32 fh 9cd: ht divisor 1 filter parent 1: protocol ip pref 48691 u32 fh 9cd::800 order 2048 key ht 9cd bkt 0 flowid 1:800 match 0a0a0b3c/ffffffff at 16 filter parent 1: protocol ip pref 48692 u32 filter parent 1: protocol ip pref 48692 u32 fh 9cc: ht divisor 1 filter parent 1: protocol ip pref 48692 u32 fh 9cc::800 order 2048 key ht 9cc bkt 0 flowid 1:798 match 0a0a0b3b/ffffffff at 16 filter parent 1: protocol ip pref 48693 u32 filter parent 1: protocol ip pref 48693 u32 fh 9cb: ht divisor 1 filter parent 1: protocol ip pref 48693 u32 fh 9cb::800 order 2048 key ht 9cb bkt 0 flowid 1:796 match 0a0a0b3a/ffffffff at 16 filter parent 1: protocol ip pref 48694 u32 filter parent 1: protocol ip pref 48694 u32 fh 9ca: ht divisor 1 filter parent 1: protocol ip pref 48694 u32 fh 9ca::800 order 2048 key ht 9ca bkt 0 flowid 1:794 match 0a0a0c70/ffffffff at 16 filter parent 1: protocol ip pref 48695 u32 filter parent 1: protocol ip pref 48695 u32 fh 9c9: ht divisor 1 filter parent 1: protocol ip pref 48695 u32 fh 9c9::800 order 2048 key ht 9c9 bkt 0 flowid 1:792 match 0a0a0120/ffffffff at 16 filter parent 1: protocol ip pref 48696 u32 filter parent 1: protocol ip pref 48696 u32 fh 9c8: ht divisor 1 filter parent 1: protocol ip pref 48696 u32 fh 9c8::800 order 2048 key ht 9c8 bkt 0 flowid 1:790 match 0a0a0683/ffffffff at 16 filter parent 1: protocol ip pref 48697 u32 filter parent 1: protocol ip pref 48697 u32 fh 9c7: ht divisor 1 filter parent 1: protocol ip pref 48697 u32 fh 9c7::800 order 2048 key ht 9c7 bkt 0 flowid 1:788
dla imq0:
filter parent 1: protocol ip pref 48691 u32 filter parent 1: protocol ip pref 48691 u32 fh 9cd: ht divisor 1 filter parent 1: protocol ip pref 48691 u32 fh 9cd::800 order 2048 key ht 9cd bkt 0 flowid 1:800 match 0a0a0b3c/ffffffff at 12 filter parent 1: protocol ip pref 48692 u32 filter parent 1: protocol ip pref 48692 u32 fh 9cc: ht divisor 1 filter parent 1: protocol ip pref 48692 u32 fh 9cc::800 order 2048 key ht 9cc bkt 0 flowid 1:798 match 0a0a0b3b/ffffffff at 12 filter parent 1: protocol ip pref 48693 u32 filter parent 1: protocol ip pref 48693 u32 fh 9cb: ht divisor 1 filter parent 1: protocol ip pref 48693 u32 fh 9cb::800 order 2048 key ht 9cb bkt 0 flowid 1:796 match 0a0a0b3a/ffffffff at 12 filter parent 1: protocol ip pref 48694 u32 filter parent 1: protocol ip pref 48694 u32 fh 9ca: ht divisor 1 filter parent 1: protocol ip pref 48694 u32 fh 9ca::800 order 2048 key ht 9ca bkt 0 flowid 1:794 match 0a0a0c70/ffffffff at 12 filter parent 1: protocol ip pref 48695 u32 filter parent 1: protocol ip pref 48695 u32 fh 9c9: ht divisor 1 filter parent 1: protocol ip pref 48695 u32 fh 9c9::800 order 2048 key ht 9c9 bkt 0 flowid 1:792
a same regulki wygladaja tak:
#!/bin/bash TC=/sbin/tc # Chwilowe pierdolniecie BURST="burst 8Mb" # Minimum pasma RATE="716800kbit" # Maximum pasma CEIL="1024000kbit" # Interfejs WAN / IMQ WAN="imq0" # Interfejs LAN LAN="eth1"
$TC qdisc del root dev $WAN $TC qdisc add dev $WAN root handle 1:0 htb $TC class add dev $WAN parent 1:0 classid 1:1 htb rate $RATE ceil $CEIL
$TC qdisc del root dev $LAN $TC qdisc add dev $LAN root handle 1:0 htb $TC class add dev $LAN parent 1:0 classid 1:1 htb rate $RATE ceil $CEIL
# POCZĄTEK WPISU DLA (ID:12) # Ciecie UPLOAD-u $TC class add dev $WAN parent 1:1 classid 1:112 htb rate 1024kbit ceil 4096kbit # Ciecie DOWNLOAD-u $TC class add dev $LAN parent 1:1 classid 1:112 htb rate 2048kbit ceil 8092kbit $BURST c$BURST $TC filter add dev $WAN protocol ip parent 1:0 u32 match ip src 10.10.9.63 flowid 1:112 $TC filter add dev $LAN protocol ip parent 1:0 u32 match ip dst 10.10.9.63 flowid 1:112 # # KONIEC DLA (ID:12) ######################
To takie stare i pewnie malo ok ale z grubsza do tej pory dzialalo. Przyklad dla jednego klienta z jednym komputerem. Bardzo tragiczne? :)
Troche w biegu odpisuje, ale wydaje mi sie, ze :
$TC filter add dev $WAN protocol ip parent 1:0 u32 match ip src 10.10.9.63 flowid 1:112
nie jest potrzebne. Masz ladne ciecie UPLOADu dla $WAN, a potem masz ciecie DOWNLOADu dla $LAN, wiec powinno zostac tylko: $TC class add dev $LAN parent 1:1 classid 1:112 htb rate 2048kbit ceil 8092kbit $BURST c$BURST $TC filter add dev $LAN protocol ip parent 1:0 u32 match ip dst 10.10.9.63 flowid 1:112
Ale jak mowie, odpisuje w biegu, wiec moge sie mylic. ;- )
W dniu 2012-09-06 12:15, Sławomir Paszkiewicz pisze:
W dniu 06.09.2012 11:51, Tomasz Chiliński pisze:
W dniu 06.09.2012 11:07, JOYNET napisał(a):
W dniu 06.09.2012 06:44, Łukasz Czerepuk pisze: Podpisuje sie z przedmowca. Mialem pododobna sytuacje. Load nie byl zbyt wysoki, a transfer konczyl sie na 100Mbps, oczywiscie linki byly pospinane na 1Gbps. A dalej wiadomo, pasmo dla klientow spadalo, telefony i tak dalej. Kolejki byly napisane z uzyciem HTB. Dla pewnosci przenioslem wszystko na inna maszyne z innymi przerwaniami, myslalem, ze to rozwiaze sytuacje. Nie pomoglo. Rozwiazaniem okazalo sie gruntowne przebudowanie kolejek. Z 20k klas HTB szedlem do 5. Teraz 250Mbps "przerabia" nawet bez zajakniecia. Polecam wiec przyjrzec sie jeszcze raz dla firewalla. Ja stawiam, albo na przerwania, albo na firewall.
W dniu 2012-09-05 23:45, joynet@vp.pl pisze:
Napisz cos wiecej o tych ipsetach, sprzet wyglada ok, problem moze byc z podzialem pasma
Jesli chodzi o ipset to wszystkie reguly ktore wczesniej obslugiwane byly poprzez iptables czyli kazdy komputer to byla jedna linijka w iptables. Teraz jest na kazda podsiec (podsieci jest 23) to osobny ipset a wiec linijek dla iptables / nat jest 23. Do tego jest troche w tabeli nat dla publicznych IP i tyle. Ogolnie duzo tego nie ma:
# iptables -t nat -L -nv|wc -l 116
# iptables -L FORWARD -nv|wc -l 36
Rzeczywiscie najwiekszym problemem moze byc HTB:
# tc qdisc show qdisc htb 1: dev eth0 root refcnt 6 r2q 10 default 0 direct_packets_stat 3072877145 qdisc htb 1: dev eth1 root refcnt 6 r2q 10 default 0 direct_packets_stat 459710 qdisc htb 1: dev imq0 root refcnt 3 r2q 10 default 0 direct_packets_stat 933285
# tc class show dev eth1|wc -l 352
# tc class show dev imq0|wc -l 352
Wlaczylem jeszcze irqbalanace. Zobaczymy czy cos sie zmieni.
irq balance niczego nie zmieni, masz do bani podzial pasma polecam przy tylu klasach sieciowych zastosowac filtry mieszajace, dzialaja super
Klasy już zobaczyliśmy, tabelę nat i trochę filter również, ale filtrów tc, ani tabeli mangle jeszcze nie ;-) Co tam takiego tajnego ukrywasz Sławku? ;-)
Nic tajnego, myslalem ze to malo znaczace ;-)
# tc filter show dev eth1|wc -l 1848
tc filter show dev imq0|wc -l 1848
No i kawalek dla eth1:
filter parent 1: protocol ip pref 48691 u32 filter parent 1: protocol ip pref 48691 u32 fh 9cd: ht divisor 1 filter parent 1: protocol ip pref 48691 u32 fh 9cd::800 order 2048 key ht 9cd bkt 0 flowid 1:800 match 0a0a0b3c/ffffffff at 16 filter parent 1: protocol ip pref 48692 u32 filter parent 1: protocol ip pref 48692 u32 fh 9cc: ht divisor 1 filter parent 1: protocol ip pref 48692 u32 fh 9cc::800 order 2048 key ht 9cc bkt 0 flowid 1:798 match 0a0a0b3b/ffffffff at 16 filter parent 1: protocol ip pref 48693 u32 filter parent 1: protocol ip pref 48693 u32 fh 9cb: ht divisor 1 filter parent 1: protocol ip pref 48693 u32 fh 9cb::800 order 2048 key ht 9cb bkt 0 flowid 1:796 match 0a0a0b3a/ffffffff at 16 filter parent 1: protocol ip pref 48694 u32 filter parent 1: protocol ip pref 48694 u32 fh 9ca: ht divisor 1 filter parent 1: protocol ip pref 48694 u32 fh 9ca::800 order 2048 key ht 9ca bkt 0 flowid 1:794 match 0a0a0c70/ffffffff at 16 filter parent 1: protocol ip pref 48695 u32 filter parent 1: protocol ip pref 48695 u32 fh 9c9: ht divisor 1 filter parent 1: protocol ip pref 48695 u32 fh 9c9::800 order 2048 key ht 9c9 bkt 0 flowid 1:792 match 0a0a0120/ffffffff at 16 filter parent 1: protocol ip pref 48696 u32 filter parent 1: protocol ip pref 48696 u32 fh 9c8: ht divisor 1 filter parent 1: protocol ip pref 48696 u32 fh 9c8::800 order 2048 key ht 9c8 bkt 0 flowid 1:790 match 0a0a0683/ffffffff at 16 filter parent 1: protocol ip pref 48697 u32 filter parent 1: protocol ip pref 48697 u32 fh 9c7: ht divisor 1 filter parent 1: protocol ip pref 48697 u32 fh 9c7::800 order 2048 key ht 9c7 bkt 0 flowid 1:788
dla imq0:
filter parent 1: protocol ip pref 48691 u32 filter parent 1: protocol ip pref 48691 u32 fh 9cd: ht divisor 1 filter parent 1: protocol ip pref 48691 u32 fh 9cd::800 order 2048 key ht 9cd bkt 0 flowid 1:800 match 0a0a0b3c/ffffffff at 12 filter parent 1: protocol ip pref 48692 u32 filter parent 1: protocol ip pref 48692 u32 fh 9cc: ht divisor 1 filter parent 1: protocol ip pref 48692 u32 fh 9cc::800 order 2048 key ht 9cc bkt 0 flowid 1:798 match 0a0a0b3b/ffffffff at 12 filter parent 1: protocol ip pref 48693 u32 filter parent 1: protocol ip pref 48693 u32 fh 9cb: ht divisor 1 filter parent 1: protocol ip pref 48693 u32 fh 9cb::800 order 2048 key ht 9cb bkt 0 flowid 1:796 match 0a0a0b3a/ffffffff at 12 filter parent 1: protocol ip pref 48694 u32 filter parent 1: protocol ip pref 48694 u32 fh 9ca: ht divisor 1 filter parent 1: protocol ip pref 48694 u32 fh 9ca::800 order 2048 key ht 9ca bkt 0 flowid 1:794 match 0a0a0c70/ffffffff at 12 filter parent 1: protocol ip pref 48695 u32 filter parent 1: protocol ip pref 48695 u32 fh 9c9: ht divisor 1 filter parent 1: protocol ip pref 48695 u32 fh 9c9::800 order 2048 key ht 9c9 bkt 0 flowid 1:792
a same regulki wygladaja tak:
#!/bin/bash TC=/sbin/tc # Chwilowe pierdolniecie BURST="burst 8Mb" # Minimum pasma RATE="716800kbit" # Maximum pasma CEIL="1024000kbit" # Interfejs WAN / IMQ WAN="imq0" # Interfejs LAN LAN="eth1"
$TC qdisc del root dev $WAN $TC qdisc add dev $WAN root handle 1:0 htb $TC class add dev $WAN parent 1:0 classid 1:1 htb rate $RATE ceil $CEIL
$TC qdisc del root dev $LAN $TC qdisc add dev $LAN root handle 1:0 htb $TC class add dev $LAN parent 1:0 classid 1:1 htb rate $RATE ceil $CEIL
# POCZĄTEK WPISU DLA (ID:12) # Ciecie UPLOAD-u $TC class add dev $WAN parent 1:1 classid 1:112 htb rate 1024kbit ceil 4096kbit # Ciecie DOWNLOAD-u $TC class add dev $LAN parent 1:1 classid 1:112 htb rate 2048kbit ceil 8092kbit $BURST c$BURST $TC filter add dev $WAN protocol ip parent 1:0 u32 match ip src 10.10.9.63 flowid 1:112 $TC filter add dev $LAN protocol ip parent 1:0 u32 match ip dst 10.10.9.63 flowid 1:112 # # KONIEC DLA (ID:12) ######################
To takie stare i pewnie malo ok ale z grubsza do tej pory dzialalo. Przyklad dla jednego klienta z jednym komputerem. Bardzo tragiczne? :)
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 06.09.2012 12:33, Łukasz Czerepuk napisał(a):
Troche w biegu odpisuje, ale wydaje mi sie, ze :
$TC filter add dev $WAN protocol ip parent 1:0 u32 match ip src 10.10.9.63 flowid 1:112
nie jest potrzebne. Masz ladne ciecie UPLOADu dla $WAN, a potem masz ciecie DOWNLOADu dla $LAN, wiec powinno zostac tylko: $TC class add dev $LAN parent 1:1 classid 1:112 htb rate 2048kbit ceil 8092kbit $BURST c$BURST $TC filter add dev $LAN protocol ip parent 1:0 u32 match ip dst 10.10.9.63 flowid 1:112
Ale jak mowie, odpisuje w biegu, wiec moge sie mylic. ;- )
2 klasy, które regulują szybkość i 2 filtry klasyfikujące na każdym z kierunków do tych klas, więc jest dobrze. Ale za to jest zupełnie nieoptymalnie, bo klasyfikowanie filtrami działa teraz tak, że dla każdego pakietu na danym kierunku przegląda wszystkie filtry i patrzy, którego warunki pasują. Przerób te filtry tak, żeby używały tabeli opartej o funkcję mieszającą (hashing table). Średnia złożoność klasyfikacji pakietów spadnie z n/2 do n/m, gdzie m będzie bardzo dużą wartością całkowitą. Dopiero wtedy można mówić o sensownej konfiguracji shapingu.
Nie wiem czemu wszyscy uparcie używają filtrów u32, skoro filtry fw z automatu są trzymane przez jądro w strukturze używającej funkcji mieszającej. Wystarczy zajrzeć do źródeł implementacji filtrów fw i widać czarno na białym.
On 09/06/2012 01:01 PM, Tomasz Chiliński wrote:
Ale za to jest zupełnie nieoptymalnie, bo klasyfikowanie filtrami działa teraz tak, że dla każdego pakietu na danym kierunku przegląda wszystkie filtry i patrzy, którego warunki pasują. Przerób te filtry tak, żeby używały tabeli opartej o funkcję mieszającą (hashing table). Średnia złożoność klasyfikacji pakietów spadnie z n/2 do n/m, gdzie m będzie bardzo dużą wartością całkowitą. Dopiero wtedy można mówić o sensownej konfiguracji shapingu.
Jako rozwiązanie pośrednie można podać moduł CLASSIFY, dzięki któremu mamy mniej reguł htb a klasyfikowanie jest robione na firewallu, gdzie możemy sobie reguły podielić na grupy (otrzymując strukturę drzewiastą) aby nie sprawdzać wszystkich. Kiedyś takie coś miałem zrobione i działało bardzo efektywnie.
W dniu 06.09.2012 13:06, A.L.E.C napisał(a):
On 09/06/2012 01:01 PM, Tomasz Chiliński wrote:
Ale za to jest zupełnie nieoptymalnie, bo klasyfikowanie filtrami działa teraz tak, że dla każdego pakietu na danym kierunku przegląda wszystkie filtry i patrzy, którego warunki pasują. Przerób te filtry tak, żeby używały tabeli opartej o funkcję mieszającą (hashing table). Średnia złożoność klasyfikacji pakietów spadnie z n/2 do n/m, gdzie m będzie bardzo dużą wartością całkowitą. Dopiero wtedy można mówić o sensownej konfiguracji shapingu.
Jako rozwiązanie pośrednie można podać moduł CLASSIFY, dzięki któremu mamy mniej reguł htb a klasyfikowanie jest robione na firewallu, gdzie możemy sobie reguły podielić na grupy (otrzymując strukturę drzewiastą) aby nie sprawdzać wszystkich. Kiedyś takie coś miałem zrobione i działało bardzo efektywnie.
Lub IPMARK i wtedy jedna reguła dla wszystkich kompów na każdy kierunek ruchu.
W dniu 06.09.2012 13:01, Tomasz Chiliński pisze:
W dniu 06.09.2012 12:33, Łukasz Czerepuk napisał(a):
Troche w biegu odpisuje, ale wydaje mi sie, ze :
$TC filter add dev $WAN protocol ip parent 1:0 u32 match ip src 10.10.9.63 flowid 1:112
nie jest potrzebne. Masz ladne ciecie UPLOADu dla $WAN, a potem masz ciecie DOWNLOADu dla $LAN, wiec powinno zostac tylko: $TC class add dev $LAN parent 1:1 classid 1:112 htb rate 2048kbit ceil 8092kbit $BURST c$BURST $TC filter add dev $LAN protocol ip parent 1:0 u32 match ip dst 10.10.9.63 flowid 1:112
Ale jak mowie, odpisuje w biegu, wiec moge sie mylic. ;- )
2 klasy, które regulują szybkość i 2 filtry klasyfikujące na każdym z kierunków do tych klas, więc jest dobrze. Ale za to jest zupełnie nieoptymalnie, bo klasyfikowanie filtrami działa teraz tak, że dla każdego pakietu na danym kierunku przegląda wszystkie filtry i patrzy, którego warunki pasują. Przerób te filtry tak, żeby używały tabeli opartej o funkcję mieszającą (hashing table). Średnia złożoność klasyfikacji pakietów spadnie z n/2 do n/m, gdzie m będzie bardzo dużą wartością całkowitą. Dopiero wtedy można mówić o sensownej konfiguracji shapingu.
Nie wiem czemu wszyscy uparcie używają filtrów u32, skoro filtry fw z automatu są trzymane przez jądro w strukturze używającej funkcji mieszającej. Wystarczy zajrzeć do źródeł implementacji filtrów fw i widać czarno na białym.
Ja korzystałem nieco z dokumentacji w LMS, troche samemu kombinowałem i to było to, co udało mi się zrobić. Może w takim razie, skoro teraz są lepsze metody to ktoś (TM) mógłby to uaktualnić w dokumentacji? Przyznam szczerze, że mi to by ułatwiło życie niż teraz szukać i kombinować i pewnie innym userom również ;-)
a same regulki wygladaja tak:
#!/bin/bash TC=/sbin/tc # Chwilowe pierdolniecie BURST="burst 8Mb" # Minimum pasma RATE="716800kbit" # Maximum pasma CEIL="1024000kbit" # Interfejs WAN / IMQ WAN="imq0" # Interfejs LAN LAN="eth1"
$TC qdisc del root dev $WAN $TC qdisc add dev $WAN root handle 1:0 htb $TC class add dev $WAN parent 1:0 classid 1:1 htb rate $RATE ceil $CEIL
$TC qdisc del root dev $LAN $TC qdisc add dev $LAN root handle 1:0 htb $TC class add dev $LAN parent 1:0 classid 1:1 htb rate $RATE ceil $CEIL
a ustaw tak:
# Minimum pasma RATE="900mbit"
$TC class add dev $WAN parent 1:0 classid 1:1 htb rate $RATE $TC class add dev $LAN parent 1:0 classid 1:1 htb rate $RATE
pozdrawiam Grzegorz Cichowski
W dniu 05.09.2012 22:33, Łukasz Matys pisze:
Wiadomość napisana przez Piotr Kaczor w dniu 5 wrz 2012, o godz. 22:26:
Kurde nie zauważyłem, ze jest tak. To jest częsty problem, że przerwania się nie wyrabiają.
PK
Na nowych plytach serwerowych intela z pci-e nie ma to juz takiego znaczenia. U nas kiedys na boradcomach powyzej 20k pps juz mielismy bledy na interfejsach.
Intele serwerowe PT lub lepiej ET to najlepsze karty na router linuxowy GE. Pozdrawiam.
Wcześniej (w tych IBM x346) były: 06:08.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 06:08.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
i byly jeszcze wieksze problemy z wydajnoscia dopoki nie zrobilem irqbalance i odchodzilem firewalla. No ale i tak to nie byla pelnia szczescia ;)
Wiadomość napisana przez Sławomir Paszkiewicz w dniu 5 wrz 2012, o godz. 20:44:
Hej,
Od pewnego czasu mamy problem z wydajnościa naszego routera. Serwer to DELL R300, dwurdzeniowy Intel(R) Xeon(R) CPU 3050 @ 2.13GHz (64bit) + 8GB ram i sieciowki Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet sztuk dwie.
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo obciazenie nie jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Odchudzilem mocno firewalla, uzywamy ipset-a w wiekszosci. Oczywiscie serwer robi NAT. Kernel: 3.3.7-1 ale na innych bylo to samo. Lacze na swiat jest OK wiec to mozna od razu wyeliminowac. Czy ktos spotkal sie z podobnym zachowaniem?
Wczesniej byl IBM x346 2x 3.2ghz CPU z HT (32bit) + 4GB ram i dzialo sie podobnie.
net.nf_conntrack_max = 65536 a aktualnie jest net.netfilter.nf_conntrack_count = 19842 a wiec jest spory zapas.
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-) Dzieki!
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Na dzien dobry zmienic karty na Intel ET Server. Pozdrawiam.
Dnia 2012-09-05, śro o godzinie 20:44 +0200, Sławomir Paszkiewicz pisze:
Serwer przy ruchu 50-60Mbps TOTAL zaczyna wariowac, tzn samo obciazenie nie jest duze (w okolicach 0.15) ale transfery u klientow spadaja 10-cio krotnie.
Osobiście uważam że przy tym sprzęcie i obciążeniu powinno być mniej niż 0.15, zobacz czy to jest obciążenie stałe, czy masz okresowe "piki".
Trace pomysly, moze ktos z Was cos podpowie z doswiadczenia ;-) Dzieki!
Nie miałeś przypadkiem awarii klimy w czasie upałów? :)
uczestnicy (13)
-
A.L.E.C -
GC -
JOYNET -
joynet＠vp.pl
-
Mariusz Kropiwnicki -
Piotr Kaczor -
Rafał Ramocki -
Rafał Ramocki -
Skiba Marek -
Sławomir Paszkiewicz -
Tomasz Chiliński -
Łukasz Czerepuk -
Łukasz Matys