Categories
Linux

Swap tuning în Linux

Acest post ar trebui să înceapă cu “DO NOT TRY THIS AT HOME” sau mai pe românește, “De încercat doar dacă nu-ți mai încapi în piele”

De când a apărut kernelul 2.6, printre multele tricuri posibile pentru tuningul sistemelor Linux se găsesc și multe moduri de a modifica comportamentul și felul de lucru cu swap-ul, și de a schimba modul în care datele vor fi scrise în swap atunci când memoria se va încărca.

Ca idee generală, atunci când o aplicație cere memorie, dar memoria RAM este încărcată total cu alte aplicații, kernelul are două opțiuni de management al memoriei: prima este să reducă cache-ul din RAM – eliminând datele vechi, sau, varianta a doua, să trimită spre swap porțiunile (paginile) mai puțin utilizate ale aplicațiilor care rulează în acel moment. E greu de spus, care variantă este mai bună și kernelul, face o balansare între cele două metode, încercând să ghicească care este mai eficientă doar în baza istoricului activităților recente.

Până la apariția kernelului 2.6. era imposibilă intervenția utilizatorului asupra modurilor de calcul și a modului de lucru, și erau destul de des întâlnite momente în care kernelul lua opțiunea greșită, acțiune finalizată cu o scădere drastică a performanțelor.

Indicele de balansare în swap, poate lua valori de la 0 la 100. La 100, kernelul va încerca întotdeauna să găsească paginile inactive și să le trimită spre disc, în swap. In cazul celălalt, factorul de apariție și redirectare către swap depinde de câtă memorie este folosită de aplicații.

Valoarea implicită este de 60.

Valoarea 0 de exemplu va duce la un comportament asemănător kernelelor vechi, unde aplicația care are nevoie de memorie poate micșora cache-ul pentru a obține o bucată din RAM.

Utilizatorii de laptopuri, vor prefera o valoare apropiată de 30, pentru a nu suprasolicita activitatea harddiscului.

Valoarea actuală a indicelui de balansare în swap se poate vedea cu:

$cat /proc/sys/vm/swappiness

Și poate fi modificat cu comanda:

$echo 30 > /proc/sys/vm/swappiness

Valoarea implicită poate fi de asemenea modificată în /etc/sysctl.conf:

vm.swappiness = 30

Revin la prima frază, nu încercați totuși să vă jucați cu treaba asta pe mașini aflate în producție… E mult mai bine să incercați pe mașini de test…și doar atunci când aveți suficient timp:)

Categories
Ubuntu

TCP/IP tunning in Ubuntu cu ajutorul sysctl

Acest articol este legat de ce setări suplimentare se mai pot face pentru a mai îmbunătăți performanțele de rețea în Linux în general și în Ubuntu în special.

Ca idee, fișierele în care ne putem “juca” de-a tunningul se găsesc in urmatoarea locatie: /proc/sys/net/ipv4

Modificarile se pot face ori direct în fișierele de aici ori, pentru a le da caracter de permanență, in: /etc/sysctl.conf  (Personal, aici îmi place mie sa le țin, pentru a le putea exporta cat mai ușor și pe alte mașini).

La fiecare mașina pe care o fac, eu personal modific (adaug dupa caz) următoarele valori:

tcp_fin_timeout : Câte secunde va aștepta TCP sa primească notificarea FIN până ce va inchide definitiv socketul de comunicare. Este ceea ce se numește pe la unii “variabilă de persistență”. Este util sa stim si să modificăm aceasta valoare pentru a putea evita eventuale atacuri de tip DOS.

tcp_syn_retries : De câte ori va incerca o conexiune TCP sa retransmită pachetele de SYN. Din punctul meu de vedere, valoarea optimă nu trebuie sa depășească 255, eu unul, o țin la 150. Oricum, se referă in principiu doar la timeout-uri pentru conexiunile spre exterior.

tcp_retries1 : Cât de des se va încerca retransmiterea răspunsultui pentru o cerere de conexiune TCP. Se refera la conexiunile către interior.

tcp_keepalive_time : Cât de des se trimit mesaje de KEEPALIVE. Valoarea de bază este de 7200 secunde.

tcp_keepalive_probes : De câte ori se va încerca retransmiterea mesajelor de KEEPALIVE până ce serverul va considera conexiunea ca fiind întreruptă.

net.ipv4.conf.all.log_martians: Se loghează pachetele care nu au identificator de inițiator, adică se prezintă ca venind de pe Marte eventual 🙂

Ca idee, trebuie sa ne jucăm cu grija prin sysctl.conf pentru ca la fel de ușor putem să și bălmăjim lucrurile încât să mergăși mai rău:)