Videre til indhold 
Jeg konfigurerer NGINX-arbejder således at worker_processes, worker_connections og worker_rlimit_nofile passer nøjagtigt sammen, og Epoll fungerer i event-loopen. Dermed bruger jeg CPU-kerner Vær effektiv, skalér antallet af samtidige forbindelser på en planlagt måde og hold latenstiderne lave ved spidsbelastninger.
Centrale punkter
Følgende centrale aspekter giver dig en hurtig oversigt over, hvordan du opretter en robust NGINX-worker-konfiguration.
- arbejdsprocesser koble det til antallet af logiske kerner, helst med „auto“.
- arbejdstager_forbindelser indstille den således, at reelle spidsbelastninger let kan dækkes.
- rlimit_nofile og øge OS-begrænsningerne i overensstemmelse med forbindelsesmængden.
- epoll og aktivere multi_accept for at udnytte event-loopen effektivt.
- Belastningstest køre og finjustere i små trin.
NGINX-arkitektur: Sådan forstår du master- og worker-servere
Jeg adskiller opgaverne fra Mester og workerne er tydelige: Masteren indlæser konfigurationer, åbner sockets og starter processer, mens workerne behandler anmodninger i event-loopen. Hver worker kører uafhængigt, reagerer på begivenheder og kan håndtere tusindvis af forbindelser uden at forårsage blokeringer. Denne model fungerer optimalt, når jeg udnytter CPU-kernerne hensigtsmæssigt og udnytter event-loopen optimalt via epoll. Jeg er opmærksom på, at hvert ekstra proxy-hop belaster forbindelsesressourcerne, hvilket afspejles i begrænsningerne. Den, der forstår rollerne, træffer bevidste beslutninger om Ressourcer og forhindrer flaskehalse i god tid.
At kombinere de tre centrale retningslinjer på den rigtige måde
Jeg overvejer arbejdsprocesser, worker_connections og worker_rlimit_nofile skal aldrig betragtes isoleret, men som en helhed. Det samlede antal mulige forbindelser beregnes ved at gange antallet af arbejdsprocesser med antallet af forbindelser pr. arbejdsproces; ud fra dette fastlægger jeg grænserne for filbeskrivere. Hvis disse indstillinger ikke stemmer overens, støder jeg på fejlen „too many open files“ eller oplever alvorlige timeouts. Ved høj belastning har jeg brug for en harmonisk kæde: tilstrækkeligt antal processer, generøse forbindelser, en passende forhøjelse af rlimit_nofile og passende OS-parametre. På den måde forhindrer jeg, at en for lille Grænse den samlede kapacitet er sat ud af drift.
worker_processes: Vælg et bestemt antal
Jeg sætter arbejdsprocesser Som regel indstilles den til „auto“, så NGINX kan genkende antallet af logiske CPU-kerner og udnytte hver enkelt kerne. Én worker pr. kerne undgår unødvendige kontekstskift og fordeler belastningen jævnt, hvilket gør reaktionstiden forudsigelig. På maskiner med meget mange kerner tester jeg bevidst også lavere antal arbejdsprocesser for at sammenligne cache-hits og kerneudnyttelse. Hvis målingerne viser, at kernerne er overbelastede, eller at TLB-misses stiger, justerer jeg antallet af arbejdsprocesser trinvist. Først måle, så ændre – sådan sikrer jeg pålidelige Resultater.
worker_connections: Forøgelse af forbindelser, der kan planlægges
Jeg vælger arbejdstager_forbindelser afhængigt af måltrafikken og protokolsammensætningen, ofte med udgangspunkt i 2048 eller 4096. For API’er med høj trafik overvejer jeg 8192, forudsat at operativsystemets begrænsninger og RAM-kapaciteten tillader det. Jeg tester hver forhøjelse med belastningstests, da åbne forbindelser binder hukommelse og påvirker upstream-adfærd. Hvis SSL-handshakes eller store uploads dominerer, orienterer jeg mig snarere efter CPU- og I/O-profiler end blot de rene forbindelsestal. På den måde sikrer jeg, at den pr. worker definerede Kapacitet også forbliver anvendelig i praksis.
Synkronisering af worker_rlimit_nofile og OS-grænser
Jeg sørger for, at rlimit_nofile dækker mindst den beregnede samlede kapacitet og er ofte konfigureret med en reserve. I reverse-proxy-scenarier regner jeg med en ekstra deskriptor til upstream pr. klientforbindelse. Derfor indstiller jeg gerne rlimit_nofile til det dobbelte af det forventede antal samtidige forbindelser. Jeg hæver kerne- og brugergrænserne (ulimit -n, fs.file-max) så meget, at NGINX rent faktisk kan udnytte værdierne. Hvis der optræder meddelelser om åbne filer i fejlloggen, hæver jeg grænserne hurtigt og overvåger Forsinkelse under belastning igen.
Begivenhedsblok: Effektiv anvendelse af epoll og multi_accept
Jeg aktiverer i begivenhedsblokken epoll og sæt multi_accept til „on“, så worker-processerne accepterer ventende forbindelser i én omgang. Epoll reducerer overhead ved mange samtidige sockets og passer godt sammen med NGINX’ ikke-blokerende design. Disse indstillinger betaler sig ved trafikspidser, fordi jeg fremskynder acceptfasen og hurtigere kommer videre til den egentlige behandling. For Linux er dette min standardindstilling, som jeg kun ændrer i sjældne, specielle tilfælde. Hvis du vil dykke dybere ned i emnet, kan du sammenligne event-loop-modellen med Threadpool kontra event-loop og drager heraf den konklusion, at konklusioner for ens eget miljø.
CPU-affinitet: Bind arbejdsprocesser til kerner
Jeg sætter worker_cpu_affinity målrettet, når arbejdsbelastningerne er konstante og CPU-afhængige. Jeg fordeler tildelingsskemaet via bitmasker for at undgå kontekstskift og fremme cache-lokalitet. Med fire kerner tildeler jeg maskerne således, at hver worker får sin egen kerne. Derefter kontrollerer jeg cache-miss-rater, median-latenser og 99-percentiler for tydeligt at kunne se effekten. Du finder en kortfattet forklaring på affinitet og NUMA på CPU-affinitet i praksis, hvilket ved finjusteringen af Arbejder-Layouts hjælper.
Kapacitetsplanlægning: Headroom og belastningstests
Når jeg opretter forbindelser, planlægger jeg en Buffer et niveau, der ligger markant over de observerede spidsbelastninger, så kortvarige stigninger ikke straks overskrider grænserne. Hvis jeg fordobler spidsbelastningen som udgangspunkt, har jeg i mange scenarier et solidt spillerum. Ved stærkt svingende trafik udvider jeg bufferen yderligere, indtil 99-percentilerne forløber problemfrit. Derefter tjekker jeg flaskehalse med værktøjer som wrk eller k6, overvåger fejlprocenterne og ser på åbne forbindelser i statusoversigten. Først når målingerne er konsistente, øger eller sænker jeg målrettet enkelte Værdier.
Konfiguration og regneeksempler
Jeg beregner forbindelseskapaciteten ved at gange antallet af arbejdere med antallet af forbindelser pr. arbejdere og fastsætter derefter de afledte grænser til et højere niveau. Med fire CPU-kerner, »auto« og 4096 forbindelser pr. arbejdere ender jeg teoretisk set på 16384 samtidige forbindelser. I proxyscenarier indstiller jeg rlimit_nofile helst til 32.768 eller derover, så upstream-sockets er inkluderet. For små maskiner med to kerner er 2048 forbindelser pr. worker ofte tilstrækkeligt, forudsat at andelen af upload og TLS forbliver moderat. Følgende tabel hjælper med at indordne Startværdier:
| CPU-kerner | arbejdsprocesser | worker_connections (Start) | Min. rlimit_nofile (vejledende værdi) | Hint |
|---|---|---|---|---|
| 2 | bil (≈2) | 2048 | ≥ 4096 | Reserve Planlægge for TLS/proxy |
| 4 | bil (≈4) | 4096 | ≥ 16 384 | Ved proxy er der ofte en faktor 2 ved FD'er |
| 8 | bil (≈8) | 4096-8192 | ≥ 32768 | Belastningstest træffer beslutning om forhøjelse |
| 16+ | bil, eventuelt færre | 8192+ | ≥ 65535 | Test med interesse og tilbageholdenhed |
NGINX-workere og upstreams: Vægtning af scenarier på den rigtige måde
Jeg skelner mellem statisk levering, reverse-proxy-drift og API-gateway-belastning, fordi de Arbejder-konfigurationen stiller forskellige krav. Statisk indhold belaster færre ressourcer, mens TLS, komprimering og upstream-forbindelser belaster CPU og FD’er i højere grad. Jo større SSL-nøglerne er, og jo flere handshakes der er, desto større fordel er der ved indstillingen „én worker pr. kerne“. Store uploads flytter fokus over på I/O, hvilket får mig til at kigge nærmere på rlimit_nofile og netværksbuffere. Ved mærkbare ventetider på modtagelse eller svar fra backend hjælper det mig at få et overblik over Køer og ventetid, for at undgå flaskehalse målrettet løse.
Arbejdsgang i praksis: Trin for trin til en hurtigere server
Jeg begynder med at kortlægge den nuværende situation for alle relevante Værdier I nginx.conf tjekker jeg CPU-kerner, ulimit og kerneparametre. Derefter indstiller jeg worker_processes til auto, sætter f.eks. worker_connections til 4096 og øger rlimit_nofile generøst. I Events-blokken aktiverer jeg epoll samt multi_accept og kontrollerer logfilerne ved at genindlæse. Derefter følger belastningstests under reproducerbare betingelser, hvor jeg overvåger responstider, fejlrater og åbne forbindelser. I finjusteringen ændrer jeg altid kun én variabel ad gangen, dokumenterer hvert trin og kontrollerer virkningerne i Metrikker.
Hostingmiljø: Ressourcer, kerne, netværk
Jeg sørger for, at der er tilstrækkeligt CPU-Kerner, tilstrækkelig RAM, hurtige SSD’er eller NVMe og en opdateret Linux-kerne. Kun på den måde fungerer epoll, moderne TCP-stakke og nyttige offload-funktioner pålideligt. Jeg tilpasser netværksparametre som somaxconn og tcp_max_syn_backlog til det forventede antal forbindelser for at holde modtagelseskøerne korte. En udbyder med robust I/O-ydeevne og frit tilgængelig systemkonfiguration betaler sig klart i denne sammenhæng. Sammenligninger viser, at tjenester med konstante Ressourcer Udvid NGINX’s fleksibilitet betydeligt.
Keepalive-strategi: Klient- og upstream-forbindelser
Jeg bruger bevidst Keepalive som et redskab til at styre kapacitet og latenstid. På klientsiden indstiller jeg keepalive_timeout ikke for højt, så inaktive sockets ikke unødigt arbejdstager_forbindelser blokere. Værdier mellem 10 og 30 sekunder giver mig ofte et godt kompromis mellem genbrug og ressourceforbrug. Med keepalive_requests begrænser jeg antallet af anmodninger pr. forbindelse for at afbryde langvarige forbindelser og undgå belastning af hukommelsen. På upstream-siden (reverse-proxy) opretholder jeg vedvarende forbindelser med keepalive i upstream-blokken, så der ikke er behov for handshakes og TCP-opsætning. Her skalerer jeg antallet pr. backend konservativt i forhold til backend-kapaciteten (max_conns), ellers opretter jeg selv køer ved upstream. Vigtigt: Hver keepalive-socket tæller som en åben forbindelse og kræver FD’er; det tager jeg højde for i rlimit_nofile og min planlægning af headroom.
Listeoptimering: Reuseport, backlog og acceptstrategi
Jeg fordeler modtagelsesbyrden jævnt ved at SO_REUSEPORT aktiver (listen … reuseport). Hver worker har dermed sin egen accept-kø, hvilket reducerer „thundering herds“ og undgår hotspots. I kombination med multi_accept fremskynder jeg modtagelsesfasen mærkbart. Listen-Efterslæb (listen … backlog=) og de tilsvarende indstillinger i kernen (somaxconn, tcp_max_syn_backlog) indstiller jeg generøst, så spidsbelastninger ikke går tabt ved socket-indgangen. Indstillingen udskudt udsætter Accept, indtil data foreligger – det kan være en hjælp, hvis der er mange kortvarige anmodninger; ellers sammenligner jeg i testene. Om jeg accept_mutex Hvad jeg har brug for, afklarer jeg i benchmark-analysen: Med reuseport er det som regel unødvendigt; uden reuseport kan det forbedre retfærdigheden, men kræver koordinering. Her træffer jeg beslutninger på baggrund af data, aldrig ud fra mavefornemmelse.
Indstil timeouts og køer, så de fungerer stabilt
Jeg sætter Timeouts således at langsomme klienter ikke overbelaster workerne: client_header_timeout og client_body_timeout Jeg holder det kort nok til at undgå afbrydelser, men generøst nok for virkelige brugere. send_timeout forhindrer, at svar til klienten bliver blokeret. I proxy-sammenhæng definerer jeg proxy_connect_timeout, proxy_read_timeout og proxy_send_timeout strengt, så de ventende backends ikke lammer frontenden. Ved backends med begrænset parallelitet bruger jeg kø i upstream-blokken med timeout for at afbøde spidsbelastninger og signalere 503 på en kontrolleret måde, i stedet for at binde alle workere til ventende upstream-sockets. Derudover stabiliserer jeg med limit_req (Burst/Delay) og limit_conn følsomme stier, så enkelte klienter eller bots ikke trækker uforholdsmæssigt mange ressourcer.
Buffering, sendfile og AIO: Bevidst valg af I/O-metoder
Jeg sætter sendfile til statiske filer og kombiner det med tcp_nopush/tcp_nodelay afhængigt af arbejdsbyrden, for at samle pakker effektivt eller reducere interaktive forsinkelser. Til store filer bruger jeg Direktion fra en bestemt tærskel, så der ikke opstår cache-forurening, og sidecachen ikke fortrænges. I proxy-tilstand beslutter jeg, om proxy_buffering hjælper (hurtig overførsel til klienten, afkoblet upstream-aflæsning), eller om jeg ved streaming-belastninger hellere bør proxy_request_buffering reducer for at igangsætte uploads i god tid. Størrelserne på proxy_buffers, proxy_buffer_size og store_klient-header-buffere Jeg styrer dette bevidst, så hukommelsesforbruget pr. forbindelse ikke eksploderer. For at skåne CPU’en ved filadgang overvejer jeg aio (native eller tråde), men test grundigt, da event-loop- og I/O-egenskaberne påvirker hinanden.
HTTP/2/HTTP/3 og TLS: Indvirkning på worker-kapaciteten
Jeg tager højde for, at HTTP/2 og HTTP/3 Ændre forbindelsesdynamikken: Mange anmodninger kører som Streams via få TCP- eller QUIC-forbindelser. Det reducerer antallet af forbindelser, men øger CPU- og hukommelsesforbruget pr. forbindelse (multiplexing, header-komprimering, TLS/QUIC). Min arbejdstager_forbindelser Derfor tolker jeg det ikke blindt som „lige mange anmodninger“. Jeg observerer samtidige strømme pr. forbindelse og passe keepalive_timeout og eventuelt. http2_max_concurrent_streams . På TLS-siden vinder jeg med session-resumption (billetter/cache) og OCSP-stapling; på den måde sparer jeg dyre handshakes og holder latenstiderne lave. Ulempen: Længere keepalives binder FD’er og RAM – derfor planlægger jeg rlimit_nofile og hukommelseskvoter med realistiske reserver. For CPU-krævende krypteringsalgoritmer er det værd at afprøve affinitet og moderne kryptografisk acceleration.
Overvågning: Status, logfiler og målinger
Jeg skaber gennemsigtighed med en strømlinet Status-Endpoint (f.eks. stub_status) for at se aktive forbindelser, Reading/Writing/Waiting og accepterede anmodninger. I logfilerne holder jeg støjniveauet lavt: En kompakt log_format med tid, status, upstream-tider og bytes er det tilstrækkeligt til de fleste analyser. Ved meget høje QPS-værdier deaktiverer jeg adgangsloggen selektivt (baseret på placering) eller bufferer logfilerne asynkront, så I/O ikke bremser systemet. Fejlloggen indstiller jeg til advarer eller fejl og skift kun kortvarigt til fejlfinding. Jeg korrelerer løbende latenstider (median/95./99. percentil), åbne forbindelser, backend-fejlprocenter og CPU-belastning pr. worker – ud fra dette udleder jeg justeringer af de tre nøgledirektiver og opdager mætningseffekter på et tidligt tidspunkt.
Containere og virtuelle miljøer: Overfør grænserne korrekt
Jeg kontrollerer i containere de cgroup-Indstil grænserne for CPU, RAM og PID'er, og afstem dem med NGINX-indstillingerne. ulimit -n skal være høj nok inden for containeren, ellers går mine justeringer af rlimit_nofile tabt. Ved CPU-kvoter (f.eks. 2 vCPU'er) indstiller jeg arbejdsprocesser I overensstemmelse hermed, så planlægningen ikke skaber unødvendig trængsel. Tæt på netværket drager jeg fordel af lavere overhead-latens i „host“-netværksmodi, mens overlay-netværk medfører yderligere hop. På Multi-NUMA-værter er jeg opmærksom på affinitet og hukommelsessokler, så arbejdsprocesser ikke arbejder på tværs af noder. Det samme gælder for IRQ- og RPS/XPS-affinitet: Hvis stierne fra NIC via IRQ til arbejdsprocessens kerne stemmer overens, falder latenstops målbart.
Forbindelsens livscyklus: Midlertidige porte, TIME_WAIT og reserver
Jeg planlægger at have nok midlertidige porte (ip_local_port_range), når NGINX fungerer som aktiv klient over for upstream-serverne. Ved meget høj forbindelseskapacitet undgår jeg overdreven portfluktuation ved hjælp af upstream-keepalive, hvilket får TIME_WAIT-stakken til at krympe. Jeg bruger kun kernel-toggles til „Reuse“ med forsigtighed; moderne stakke optimerer allerede meget internt. Det er mere stabilt at styre forbindelsernes varighed via fornuftige keepalive- og timeout-værdier og reuseport til at sikre en retfærdig fordeling. I kapacitetsberegningen tager jeg ud over klienterne altid højde for upstream-siden – ofte er det FD’erne der, der udgør den egentlige begrænsende faktor, ikke frontdoor.
Smidige genindlæsninger og implementeringer uden afbrydelser
Jeg bruger master/worker-modellen til smidige genindlæsninger: Masteren indlæser nye konfigurationer, gamle workere lukkes ned, mens nye problemfrit overtager. Med worker_shutdown_timeout giver jeg anmodningerne tid til at afsluttes korrekt uden at blokere ressourcer. Zero-Downtime-implementeringer på upstream kombinerer jeg med sundhedstjek og proxy_next_upstream-Regler, der sikrer, at enkelte fejlramte backends ikke øger den samlede latenstid. Når jeg ændrer konfigurationen, ændrer jeg altid kun én indstilling ad gangen og verificerer effekterne i logfiler og målinger – på den måde undgår jeg fejl som følge af forvirring og sikrer, at ydeevnen forbliver reproducerbar.
Kortfattet resumé
Jeg kobler arbejdsprocesser Indstil antallet af kerner (helst automatisk), sæt worker_connections i overensstemmelse med spidsbelastningen, og øg rlimit_nofile samt operativsystemets grænser generøst. I Events-blokken bruger jeg epoll og multi_accept, tester det hele med reproducerbare belastningstests og justerer derefter i små trin. Ved proxy-arbejdsbelastninger tager jeg højde for ekstra deskriptorer og tester CPU-affinitet, når arbejdsbelastningerne er konstante. En korrekt konfigureret stack med den rette kerne, hurtig I/O og fornuftige netværksparametre gør hele forskellen. Sådan opnår jeg NGINX pålideligt inden for det ydeevneområde, som krævende websteder og API’er har brug for.
