Linuxi jõudluse suurendamine

Allikas: Kuutõrvaja

Linuxi wõrgutuuning

Kõigepealt parema kiiruse saavutamiseks vajalik. Optimeeritud puhuks, kus mõlemad pooled on gigabiti otsas. Mõju on kohati päris suur, näiteks testi puhul kasvas kiirus 500Mbit/s -> 750 MBit/s võrreldes vaikeväärtustega.

TCP akna mõõdud. Normaaljuhul ei tohiks min väärtust nii suureks keerata (default on 4k) ja max väärtuse veel suuremaks ajamisest pole minu katsetuste põhjal kasu. Ühest küljest konservatiivne ja teisest küljest mitteahistav valik võiks olla 4k <midagi> 2M.

net.ipv4.tcp_rmem = 131072 1048576 2097152
net.ipv4.tcp_wmem = 131072 1048576 2097152
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.rmem_max = 2097152
net.core.wmem_max = 2097152

Vastuvõtva järjekorra suurus (saatmisjärjekord seevastu peaks olema lühike, seal on liigne puhverdamine kahjulik)

net.core.netdev_max_backlog = 10000

Need on jällegi gigabitist maksimumi pigistamiseks, tavaolukorras las jäävad pigem sisselülitatuks.

net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_sack = 0

Serveri puhul on suure ühenduste arvu teenindamiseks vaja suuremaks keerata järgmisi asju:

fs.file-max
net.ipv4.tcp_max_orphans
net.ipv4.tcp_max_tw_buckets

Sõltuvalt masinast

net.ipv4.tcp_mem

Ja kui iptablesi reeglid on conntracki käima tõmmanud siis ka

net.netfilter.nf_conntrack_max

Lisaks veel, interruptide sidumise konkreetse tuuma külge teeb tavaliselt ära irqbalance, ise kruvimise huvi korral saab seda /proc/irq kaudu. Protsesside sidumiseks tuumaga on käsud taskset ja schedtool -- viimane oskab ka palju muud huvitavat.

http://www.twam.info/linux/changing-scheduling-parameters-in-linux

The default is to run a process on all CPUs, giving a mask of

   0xf for all 4 CPUs
   0xff for all 8 CPUs
# schedtool -a 0xff <PID>
# schedtool -a 0xff -e /path/to/app arg1 arg2 argN

Tcp2 0110.gif

SYN floodi vastu kaitseb sysctl muutja

net.ipv4.tcp_syncookies = 1

Lahendus toimib selliselt, et kernel küll võtab SYN paketi vastu, kuid registreerib selle esialgu enda oma puhvris (syncache) ning ootab kuni ühenduse loomine on kliendi poolt korrektselt lõpuni viidud. Sedamoodi püsivad võrgupuhvrid tühjad ja võtavad vähem resrusse näiteks SYN Flood korral.

Lisaks tasub suurendada ka SYN backlogi suurust (vaikimisi 1024)

Sissetulevad ühendused, mida pole veel teenindada jõutud.

sysctl -w net.ipv4.tcp_max_syn_backlog=2048


# netstat -tuna | grep :80 | grep SYN_RECV
# netstat -ant | grep 80 | awk '{print $6}' | sort | uniq -c | sort -n
      1 CLOSE_WAIT
      1 LISTEN
     10 FIN_WAIT1
     12 LAST_ACK
     25 SYN_RECV
    102 FIN_WAIT2
    106 ESTABLISHED
   1536 TIME_WAIT


After you do the above, SYN Flood attacks will continue, but it will not affect the server negatively. You will see a message like this in your logs:

[1116377.589736] possible SYN flooding on port 80. Sending cookies. [1116439.567828] possible SYN flooding on port 80. Sending cookies. [1116500.631623] possible SYN flooding on port 80. Sending cookies.

http://en.wikipedia.org/wiki/SYN_flood