Linuxi jõudluse suurendamine

Süsteemi tuunimine

Masinatel, kus rakendus avab palju faile ja/või võrguühendusi (näiteks logiserver, DB):

$ ulimit -n
  65535

Vaikimisi 1024.

Järgnev on parema võrgukiiruse saavutamiseks juhul 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

Liskas tasub disableda slow-start, et võrgust maksimum välja pigistada:

 net.ipv4.tcp_slow_start_after_idle = 0

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 moodi masinatel - määrab ära ootel ühenduste max arvu:

  net.core.somaxconn = 1024
  net.ipv4.tcp_max_syn_backlog = 8096

Vaikimisi 128.

Masinatel mis teevad palju ühendusi väljapoole (ntx vpn hub, load balancer):

 net.ipv4.tcp_tw_reuse = 1
 net.ipv4.ip_local_port_range = 10240 65535

Vaikimisi "2" ja "32768 60999".

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

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

Vaatamiseks ja debugimiseks sobivad käsud

# 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.

Lingid

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

https://www.slideshare.net/brendangregg/how-netflix-tunes-ec2-instances-for-performance