Ubrzavanje Linux poslužitelja za web radna opterećenja

Poslužitelj koji se čini sporim ne znači automatski da mu trebaju veće vrijednosti worker_connections ili novi blok sysctl postavki. Razlog može biti zasićenje CPU-a, latencija pohrane, prepun red veza, premali aplikacijski spremnik ili ovisnost prema vanjskoj usluzi. Podešavanje performansi stoga je petlja mjerenja: definirajte radno opterećenje, uhvatite početno stanje, promijenite jednu varijablu, ponovo izmjerite i pripremite testiranu opciju povrata.

Krenite od početnog stanja, ne od recepta

Zabilježite broj zahtjeva u sekundi, p50/p95/p99 latencije, stopu HTTP pogrešaka i točan URL ili transakciju koju testirate. Tijekom reprezentativnog razdoblja prikupite iskorištenost i zasićenost sustava:

uptime
free -m
vmstat 1
mpstat -P ALL 1
iostat -xz 1
pidstat 1
ss -s

Prosječno opterećenje iz naredbe uptime treba tumačiti u kontekstu: može obuhvaćati zadatke koji čekaju ulaz/izlaz, a ne samo izvršive procese na CPU-u. Izlaz vmstat pokazuje red čekanja, zamjensku memoriju i blokirane zadatke, dok iostat -xz pomaže razlikovati zauzet disk od pasivnog. Za usporedbu prije i poslije održavajte isto trajanje testa, broj istovremenih klijenata, stanje predmemorije i lokaciju klijenta. Pokretanje benchmarka na samom poslužitelju može mjeriti lokalno petljanje umjesto mrežnog puta koji korisnici doživljavaju.

Dubinska istraživanja koristi metodu USE: provjerite iskorištenost, zasićenost i greške za svaki resurs. Brendan Greggov priručnik za aktivno benchmarkiranje podsjeća da kratak test može analizirati jednu komponentu dok mislite da mjerite cijelu uslugu.

Nginx: uskladite kapacitet s radnim opterećenjem

Nginx dokumentira worker_processes auto kao razuman početak jer pokušava detektirati dostupne CPU jezgre. To nije jamstvo da je jedan podproces po jezgri optimalno rješenje: TLS obrada, kompresija, čekanja prema udaljenom poslužitelju i vezanje CPU-a mogu promijeniti rezultat. Zadana vrijednost za worker_connections iznosi 512 i računa i konekcije prema pozadinskim poslužiteljima, a ne samo direktne veze preglednika. Njegova efektivna granica ograničena je i brojem deskriptora datoteka pojedinog podprocesa. Naša ranija analiza limita deskriptora datoteka i Nginx worker connections obrađuje taj odnos detaljno.

Mali, mjerljiv početak može izgledati ovako:

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 2048;
}

http {
    sendfile on;
    keepalive_timeout 30s;
    keepalive_requests 1000;
}

Ovo su primjeri, a ne univerzalni ciljevi. keepalive_timeout ima zadanih 75 sekundi, a keepalive_requests ima zadanih 100 u trenutnoj Nginx dokumentaciji; skraćivanje ili produljenje mijenja kompromise memorije, ponovne uporabe veza i latencije. Povratni proxy također treba usklađenu keepalive konfiguraciju za pozadinske poslužitelje, dok statički server fileova možda više profitira od ispravnih cache zaglavlja i ponašanja predmemorije stranica nego od dodatnih podprocesa. Koristite nginx -t prije ponovnog učitavanja i usporedite brojeve veza i krajnju latenciju nakon promjene. sendfile on može smanjiti kopije za statičke datoteke, ali filtri koji transformiraju sadržaj — poput kompresije — mogu spriječiti primjenu zero-copy puta.

Redovi i deskriptori datoteka

Pročitajte trenutne vrijednosti prije nego što ih mijenjate:

sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog
ulimit -Sn
ulimit -Hn
sysctl fs.file-max fs.nr_open

Moderni kerneli dokumentiraju net.core.somaxconn na 4096 (prije Linuxa 5.4 bilo je 128), ali vrijednost ima smisla samo kada su listen backlog redovi u aplikaciji i Nginxu međusobno usklađeni. Ako namjerno postavite Nginx listen ... backlog=, uskladite oba reda i promatrajte ponašanje pod opterećenjem. tcp_max_syn_backlog pokriva djelomično uspostavljene TCP veze; dizanje njegove vrijednosti odgovor je na opaženi pritisak, a ne zamjena za rješavanje spore aplikacije.

Ograničenja po podprocesu, systemd-ov LimitNOFILE, fs.nr_open i sistemski fs.file-max različiti su kontrolni parametri. Dizanje jednog ograničenja dok ostaje niži ne stvara kapacitet. systemd LimitNOFILE dokumentacija i kernel filesystem sysctl dokumentacija objašnjavaju granice. Stare recepte za tcp_tw_reuse, syncookies i ogromne fs.file-max vrijednosti provjerite sumnjičavo: trenutna kernel semantika i zadane vrijednosti imaju važnosti, a syncookies su sigurnosni mehanizam za zaštitu od SYN flood napada, a ne alat za skaliranje normalnog prometa.

Memorija, pohrana i aplikacijski spremnici

Zadana kernelova vm.swappiness iznosi 60 na modernim Linux sustavima s rasponom 0–200. Vrijednost preko 100 posebno je opisana kao potencijalno korisna za brzu zamjensku memoriju u RAM-u poput zram ili zswap; nije to generička postavka „učini poslužitelje bržima”. vm.vfs_cache_pressure ima zadanih 100. Snižavanje potiče kernel da radije zadržava dentry i inode cache, što može pomoći radnim opterećenjima koja puno rade s metapodacima, ali se može natjecati s aplikacijskom memorijom. Izmjerite oslobađanje memorije, velike paginacijske greške i aplikacijski RSS prije nego dodirnete bilo koju od tih postavki. Kernel VM dokumentacija autoritavan je izvor za trenutno ponašanje.

Za PHP-FPM, pm.max_children granična je vrijednost za koncurrentne zahtjeve. Veličinu odredite iz mjerenog prosječnog zauzimanja memorije podprocesa i memorije stvarno dostupne nakon budžeta OS-a, baze podataka i cachea — ne iz formulâ koje ste negdje vidjeli. Heuristika dostupna aplikacijska memorija / prosječno zauzeće memorije podprocesa je samo početna procjena; ostavite rezervu i provjerite redove, latenciju i korištenje zamjenske memorije. pm.max_requests ima zadano unlimited i može se postaviti za ponovno pokretanje podprocesa kada biblioteka curi memoriju. request_terminate_timeout štiti spremnik od patoloških zahtjeva. Node, Python, Gunicorn i drugi interpreti imaju analogne podproscesne ili nitne spremnike: identificirajte usko grlo spremnika prije nego povećavate Nginx kapacitet.

Predmemorija ima nekoliko slojeva s različitim načinima neuspjeha: predmemorija datotečnog sustava, Nginx proxy ili FastCGI cache, HTTP Cache-Control zaglavlja i PHP opcache. Osvježite svaki sloj namjerno. Povećanje stope pogodaka koje služi zastarjeli ili personalizirani sadržaj nije uspjeh performansi.

Validirajte, pratite i vratite na prethodnu verziju

Pokrenite wrk, hey ili usporedivi alat s klijenta sa zasebnog stroja, stabilno dulje vrijeme dovoljno da se dostigne stabilno stanje. Promatrajte vmstat, mpstat, iostat, ss -s, Nginx zapisnice pristupa i aplikacijske metrike dok test traje. Usporedite percentile i stope grešaka, ne samo prosječnu latenciju. Za kontinuiranu vidljivost, zadržite sysstat povijest i izložite Nginx ili PHP-FPM status endpointove samo pouzdanim adresama za nadzor; ti endpointovi otkrivaju operativne detalje.

Promjene napravljene s sysctl -w nestaju pri ponovnom pokretanju sustava. Ako promjena pomaže, zabilježite je u namjenskom /etc/sysctl.d/99-web-tuning.conf, primijenite s sysctl --system i čuvajte datoteku u sustavu za kontrolu verzija. Za prevladavanje systemd postavki koristite systemctl daemon-reload, validirajte jedinicu i ponovno pokrenite samo kada je potrebno. Povratite se restauracijom prethodne vrijednosti ili uklanjanjem datoteke koja poništava zadanu postavku, zatim ponovno pokrenite isti početni test. Nikada ne koristite echo 1 > /proc/sys/vm/drop_caches kao popravak za podešavanja; to je dijagnostičko djelovanje koje namjerno odbacuje korisno stanje predmemorije.

Prava vrijednost ovisi o tome poslužuje li stroj statične assetove, terminira TLS, proxira aplikaciji ili također hosta bazu podataka. Izmjerite usko grlo, napravite najmanju moguću promjenu, validirajte ga pod pravim radnim opterećenjem i držite staru konfiguraciju na dohvat jedne naredbe.

Izvori i dalje čitanje

• Dokumentacija Nginx core modula
• Dokumentacija Nginx HTTP core modula
• Dokumentacija Nginx upstream keepalive modula
• F5: Tuning NGINX for Performance
• Dokumentacija Linux kernela: sysctl za VirtualMemory
• Dokumentacija Linux kernela: sysctl za mrežu
• PHP-FPM priručnik za konfiguraciju
• Netflix: Analiza performansi Linuxa za 60 000 milisekundi