2011/2/21 Bogdan-Stefan Rotariu <bog...@rotariu.ro>
> [...]
> 1. La routing, singura balansare care ai putea sa o faci este cea de IRQ
> pe diferite procesoare/core-uri, dar si pentru asta ai nevoie de mult
> tweaking.
>
Uhm, la mine tweakingul pentru asta inseamna disable la irqbalance si
urmatoarele linii puse la startup,
# IRQ affinities
eth0_irq=`grep eth0 /proc/interrupts|cut -d \: -f 1 | awk '{print $1}'`
eth1_irq=`grep eth1 /proc/interrupts|cut -d \: -f 1 | awk '{print $1}'`
eth2_irq=`grep eth2 /proc/interrupts|cut -d \: -f 1 | awk '{print $1}'`
# eth0 goes on CPU1, eth1 on CPU2, eth2 on CPU3 and timer on CPU0
echo "1" >/proc/irq/0/smp_affinity
echo "2" >/proc/irq/$eth0_irq/smp_affinity
echo "4" >/proc/irq/$eth1_irq/smp_affinity
echo "8" >/proc/irq/$eth2_irq/smp_affinity
> 2. Conteaza foarte mult ce placi de retea ai, sa cresti bufferul la 4096
> (e1000) va treubi sa scazi timpul la softIRQ pentru procesarea fiecarui
> pachet, cresterea tabelei de hash, mornirea irqbalance cu --noethernet,
> sa nu te bagi peste setarile de smpaffinity de la placile de retea
>
>
Tweakingul la parametrii placilor Intel, din experienta mea, nu ajuta foarte
mult -- eu am reusit sa obtin maxim 30% performante in plus cu diverse
modificari.
Ultimele generatii de drivere de la Intel au un mod "adaptive" la unii
parametri, din experienta mea isi fac treaba bine.
> Iti recomand sa nu folosesti iptables, in special NU NAT, mai exact sa-i
> dai disable de tot, mai economisesti din timpul petrecut sa rezolvi
> problemele cauzate de iptables, sa incerci sa iti rulezi servicii doar
> pe interfete locale de management/vlan-uri
>
> Poti sa scazi tcp_wait sa reduci numarul de conexiuni din tabela, (eu le
> foloseam intre 60-360 de secunde, fata de 1h cat era default)
>
>
Subscriu la aceste ajustari de TCP. Sunt si altele in afara de tcp_wait,
google dupa "linux tcp tweaking high traffic" gaseste cateva resurse
interesante.
OP: Intr-un scenariu de acest tip (linux pe post de router cu quagga), cele
mai mari si mai uzuale probleme sunt la situatiile de atac [D]DoS.
In cazul unui client de-al meu, la peste 70kpps, softinterrupts consuma
maxim CPU si apare packetloss consistent.
Am rezolvat situatiile astea cu tool-ul numit glflow. Consuma destul CPU
(25% dintr-un core de Xeon 3GHz), insa detecteaza flood-urile suficient de
bine si repede.
Pentru filtrare folosesc iptables pe tabela raw (care e parcursa inainte de
connection tracking). Daca e cineva interesat de setup, pot sa dau detalii
pe personala.
--
www.flo.ro
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
