Hoppa till innehåll 
Jag konfigurerar NGINX-arbetare så att worker_processes, worker_connections och worker_rlimit_nofile stämmer exakt överens och Epoll fungerar i händelseslingan. På så sätt använder jag CPU-kärnor Effektiv, möjliggör planerbar skalning av samtidiga anslutningar och håll latensen låg vid belastningstoppar.
Centrala punkter
Följande nyckelaspekter ger dig omedelbar vägledning för en stabil NGINX-Worker-konfiguration.
- arbetare_processer koppla till antalet logiska kärnor, helst med „auto“.
- arbetare_anslutningar ställa in så att verkliga toppar täckas utan problem.
- rlimit_nofile och höja OS-gränserna i enlighet med anslutningsvolymen.
- epoll och aktivera multi_accept för att utnyttja händelseslingan effektivt.
- Belastningsprov köra och finjustera i små steg.
NGINX-arkitektur: Att förstå master- och worker-instanser
Jag skiljer uppgifterna från Mästare och arbetare: Mastern laddar konfigurationer, öppnar socklar och startar processer, medan arbetarna bearbetar förfrågningar i händelseslingan. Varje arbetare körs självständigt, reagerar på händelser och kan hantera tusentals anslutningar utan att orsaka blockeringar. Denna modell fungerar utmärkt när jag utnyttjar CPU-kärnorna på rätt sätt och utnyttjar händelseslingan optimalt via epoll. Jag är medveten om att varje ytterligare proxy-hopp tar upp anslutningsresurser, vilket återspeglas i gränserna. Den som förstår rollerna kan fatta medvetna beslut om Resurser och förebygger flaskhalsar i ett tidigt skede.
Att koppla samman de tre nyckelriktlinjerna på rätt sätt
Jag överväger arbetare_processer, worker_connections och worker_rlimit_nofile ska aldrig justeras var för sig, utan som en helhet. Det totala antalet möjliga anslutningar beräknas genom att multiplicera antalet arbetare med antalet anslutningar per arbetare; utifrån detta fastställer jag gränsvärden för filbeskrivare. Om dessa inställningar inte stämmer överens stöter jag på felet „too many open files“ eller drabbas av hårda timeouts. Vid hög belastning behöver jag en välavstämd kedja: tillräckligt många processer, generösa anslutningar, ordentligt höjt rlimit_nofile och lämpliga operativsystemparametrar. På så sätt förhindrar jag att ett för litet Begränsa hela kapaciteten har minskats.
worker_processes: Välj antal medvetet
Jag ställer in arbetare_processer vanligtvis inställd på „auto“, så att NGINX kan identifiera antalet logiska CPU-kärnor och utnyttja varje kärna. En worker per kärna undviker onödiga kontextbyten och fördelar belastningen jämnt, vilket gör att svarstiden förblir förutsägbar. På maskiner med väldigt många kärnor testar jag medvetet även lägre antal arbetare för att jämföra cacheträffar och kärnutnyttjande. Om mätvärdena visar att kärnorna är överbelastade eller att TLB-missar ökar, justerar jag antalet arbetare stegvis. Först mäta, sedan ändra – så säkerställer jag tillförlitliga Resultat.
worker_connections: Öka antalet anslutningar på ett planerat sätt
Jag väljer arbetare_anslutningar beroende på måltrafik och protokollmix, ofta med utgångspunkt från 2048 eller 4096. För API:er med hög trafik överväger jag 8192, förutsatt att operativsystemets begränsningar och RAM-minnet tillåter det. Varje ökning testar jag med belastningstester, eftersom öppna anslutningar binder minne och påverkar uppströmsbeteendet. Om SSL-handskakningar eller stora uppladdningar dominerar utgår jag hellre från CPU- och I/O-profiler, inte bara från rena anslutningssiffror. På så sätt säkerställer jag att den per arbetare definierade Kapacitet förblir praktiskt användbar.
Synkronisera worker_rlimit_nofile och operativsystemets gränsvärden
Jag ser till att rlimit_nofile täcker åtminstone den beräknade totalkapaciteten och är ofta konfigurerad med en reserv. För reverse-proxy-scenarier räknar jag in en andra deskriptor till uppströms per klientanslutning. Därför ställer jag gärna in rlimit_nofile till dubbelt så högt som det förväntade antalet samtidiga anslutningar. Jag höjer kärn- och användargränserna (ulimit -n, fs.file-max) så att NGINX faktiskt kan utnyttja värdena. Om det dyker upp meddelanden om öppna filer i felloggen höjer jag gränserna snabbt och övervakar Fördröjning under belastning igen.
Evenemangsblock: effektiv användning av epoll och multi_accept
Jag aktiverar i händelseblocket epoll och ställer in multi_accept på „on“, så att arbetare tar emot väntande anslutningar i en enda omgång. Epoll minskar overhead vid många samtidiga socklar och passar väl ihop med NGINX:s icke-blockerande design. Dessa inställningar lönar sig vid trafiktoppar, eftersom de påskyndar mottagningsfasen och gör att jag snabbare kommer vidare till själva bearbetningen. För Linux är detta min standardinställning, som jag endast ändrar i sällsynta specialfall. Den som vill fördjupa sig ytterligare kan jämföra event-loop-modellen med Trådpool kontra händelseslinga och drar därav slutsatsen att slutsatser för sin egen omgivning.
CPU-affinitet: Binda arbetare till kärnor
Jag ställer in worker_cpu_affinity använder jag detta specifikt när arbetsbelastningarna är konstanta och CPU-bundna. Jag fördelar tilldelningsschemat via bitmasker för att undvika kontextbyten och främja cache-lokalitet. Med fyra kärnor tilldelar jag maskerna så att varje arbetare får en egen kärna. Därefter kontrollerar jag cache-miss-frekvenser, medianlatenser och 99-percentiler för att tydligt se effekten. Mer detaljerad information om affinitet och NUMA hittar du sammanfattat på CPU-affinitet i praktiken, vilket vid finjusteringen av Arbetare-Layouts är till hjälp.
Kapacitetsplanering: Reservkapacitet och belastningstester
När det gäller kopplingar planerar jag en Buffert ett värde som ligger betydligt över de observerade topparna, så att kortvariga toppar inte direkt överskrider gränsvärdena. Om jag dubblar toppbelastningen som utgångspunkt får jag i många scenarier ett gediget utrymme. Vid kraftigt fluktuerande trafik utökar jag buffertmarginalen ytterligare tills 99-percentilen ser stabil ut. Därefter kontrollerar jag flaskhalsar med verktyg som wrk eller k6, övervakar felprocenten och tittar på öppna anslutningar i statusen. Först när mätvärdena är konsekventa höjer eller sänker jag specifikt enskilda Värden.
Konfiguration och räkneexempel
Jag beräknar anslutningskapaciteten genom att multiplicera antalet arbetare med antalet anslutningar per arbetare och sätter sedan gränserna något högre utifrån detta. Med fyra CPU-kärnor, inställningen ”auto” och 4096 anslutningar per arbetare hamnar jag enligt beräkningarna på 16 384 samtidiga anslutningar. I proxyscenarier brukar jag sätta rlimit_nofile till 32 768 eller högre, så att uppströms-socklar ingår. För små maskiner med två kärnor räcker det ofta med 2 048 anslutningar per arbetare, förutsatt att andelen uppladdningar och TLS-anslutningar förblir måttlig. Följande tabell hjälper till att klassificera Startvärden:
| CPU-kärnor | arbetare_processer | worker_connections (Start) | Min. rlimit_nofile (riktvärde) | Ledtråd |
|---|---|---|---|---|
| 2 | bil (≈2) | 2048 | ≥ 4096 | Reserv Planera för TLS/proxy |
| 4 | bil (≈4) | 4096 | ≥ 16 384 | Vid proxy är det ofta faktor 2 vid FD:er |
| 8 | bil (≈8) | 4096-8192 | ≥ 32 768 | Belastningstest beslutar om höjning |
| 16+ | bil, eventuellt färre | 8192+ | ≥ 65535 | Testa med känsla och återhållsamhet |
NGINX-arbetare och uppströms: Att viktiga scenarier på rätt sätt
Jag skiljer mellan statisk leverans, reverse proxy-drift och API-gateway-belastning, eftersom de Arbetare-Konfigurationen ställer olika krav. Statiskt innehåll tar mindre resurser i anspråk, medan TLS, komprimering och uppströmsanslutningar belastar CPU och filbeskrivare (FD) mer. Ju större SSL-nycklarna är och ju fler handskakningar som krävs, desto större fördelar ger inställningen „en worker per kärna“. Stora uppladdningar förskjuter profilen mot I/O, vilket gör att jag snarare fokuserar på rlimit_nofile och nätverksbuffertar. Vid märkbara väntetider för mottagning eller svar från backend hjälper översikten mig att Köer och latens, för att undvika flaskhalsar riktade lösa.
Arbetsflöde i praktiken: Steg för steg mot en snabbare server
Jag börjar med att göra en kartläggning av alla relevanta Värden I nginx.conf kontrollerar jag CPU-kärnor, ulimit och kärnparametrar. Därefter ställer jag in worker_processes på auto, anger worker_connections till exempelvis 4096 och höjer rlimit_nofile generöst. I Events-blocket aktiverar jag epoll och multi_accept och kontrollerar loggarna med en omladdning. Därefter följer belastningstester under reproducerbara förhållanden, där jag observerar svarstider, felfrekvenser och öppna anslutningar. I finjusteringen ändrar jag alltid bara en variabel, dokumenterar varje steg och kontrollerar effekterna i Mätetal.
Webbhotellsmiljö: resurser, kärna, nätverk
Jag ser till att det finns tillräckligt med CPU-Kärnor, tillräckligt med RAM, snabba SSD-enheter eller NVMe och en aktuell Linux-kärna. Endast på detta sätt fungerar epoll, moderna TCP-stackar och användbara avlastningsfunktioner på ett tillförlitligt sätt. Jag anpassar nätverksparametrar som somaxconn och tcp_max_syn_backlog efter det önskade antalet anslutningar för att hålla mottagningsköerna korta. En leverantör med stabil I/O-prestanda och fritt tillgänglig systemkonfiguration lönar sig klart i detta sammanhang. Jämförelser visar att tjänster med konstanta Resurser Öka NGINX:s flexibilitet avsevärt.
Keepalive-strategi: Klient- och uppströmsanslutningar
Jag använder Keepalive medvetet som ett verktyg för att påverka kapacitet och latens. På klientsidan använder jag keepalive_timeout inte för högt, så att inaktiva socklar inte i onödan arbetare_anslutningar blockera. Värden mellan 10–30 s ger mig ofta en bra avvägning mellan återanvändning och resursbindning. Med keepalive_requests begränsar jag antalet förfrågningar per anslutning för att stoppa långvariga anslutningar och undvika belastning på minnet. På uppströmsidan (reverse-proxy) upprätthåller jag beständiga anslutningar med keepalive i uppströmsblocket, vilket innebär att handskakningar och TCP-uppkoppling inte behövs. Jag skalar då antalet per backend konservativt i förhållande till backend-kapaciteten (max_conns), annars skapar jag själv köer vid uppströmsförsändningen. Viktigt: Varje keepalive-socket räknas som en öppen anslutning och kräver FD:er; det tar jag hänsyn till i rlimit_nofile och min planering av utrymmet.
Listoptimering: reuseport, backlog och acceptansstrategi
Jag fördelar belastningen jämnt genom att SO_REUSEPORT aktivera (listen … reuseport). Varje worker har därmed en egen accept-kö, vilket minskar „thundering herds“ och förhindrar flaskhalsar. I kombination med multi_accept på så sätt påskyndar jag mottagningsfasen märkbart. Listan-eftersläpning (listen … backlog=) och motsvarande inställningar i kärnan (somaxconn, tcp_max_syn_backlog) ställer jag in generöst, så att toppar inte går förlorade vid socket-ingången. Alternativet uppskjuten skjuter upp Accept tills data finns tillgängliga – vid många kortlivade förfrågningar kan det vara till hjälp, annars jämför jag i tester. Om jag accept_mutex Vad jag behöver avgör jag utifrån jämförelsen: Med reuseport är det oftast onödigt; utan reuseport kan det förbättra rättvisan, men kräver samordning. Här fattar jag beslut utifrån data, aldrig på känsla.
Stabil inställning av timeouts och köer
Jag ställer in Tidsfrister så att långsamma klienter inte överbelastar arbetarna: client_header_timeout och klient_kropp_timeout Jag håller det tillräckligt kort för att undvika avbrott, men tillräckligt omfattande för verkliga användare. send_timeout skyddar mot blockerade svar till klienten. I proxysammanhanget definierar jag proxy_anslutning_timeout, proxy_read_timeout och proxy_send_timeout strikt, så att hängande backend-processer inte lamslår frontenden. För backend-processer med begränsad parallellitet använder jag kö i uppströmsblocket med timeout för att dämpa toppar och på ett kontrollerat sätt signalera 503, istället för att binda alla arbetare till väntande uppströms-socklar. Dessutom stabiliserar jag med limit_req (Burst/Delay) och limit_conn känsliga vägar, så att enskilda klienter eller botar inte tar upp oproportionerligt mycket resurser.
Buffring, sendfile och AIO: Att medvetet välja I/O-metoder
Jag ställer in sendfile för statiska filer och kombinera det med tcp_nopush/tcp_nodelay beroende på arbetsbelastningen, för att effektivt sammanföra paket eller minska fördröjningarna vid interaktiva uppgifter. För stora filer använder jag direktiv från och med ett visst tröskelvärde, så att cacheförorening undviks och sidcachen inte trängs undan. I proxyläge bestämmer jag om proxy_buffering hjälper (snabb överföring till klienten, avkopplad uppströmsavläsning) eller om jag vid strömmingsbelastningar hellre bör proxy_request_buffering minska för att sätta igång uppladdningarna i god tid. Storlekarna på proxy_buffers, proxy_buffer_size och stora_klienthuvudbuffertar Jag styr detta medvetet för att minnesanvändningen per anslutning inte ska skjuta i höjden. För att minska belastningen på processorn vid filåtkomst överväger jag aio (native eller trådar), men testa noggrant, eftersom event-loopens och I/O:s egenskaper påverkar varandra.
HTTP/2/HTTP/3 och TLS: Effekter på arbetarkapaciteten
Jag tar hänsyn till att HTTP/2 och HTTP/3 Ändra anslutningsdynamiken: Många förfrågningar körs som Strömmar via ett fåtal TCP- respektive QUIC-anslutningar. Detta minskar antalet anslutningar, men ökar samtidigt CPU- och minnesbehovet per anslutning (multiplexering, header-komprimering, TLS/QUIC). Min arbetare_anslutningar Därför tolkar jag det inte blint som „lika många förfrågningar“. Jag observerar parallella strömmar per anslutning och passning keepalive_timeout och eventuellt. http2_max_concurrent_streams . På TLS-sidan vinner jag på session-resumption (biljetter/cache) och OCSP-stapling; på så sätt slipper jag kostsamma handskakningar och håller latensen låg. Nackdelen: Längre keepalives binder upp filer och RAM – därför planerar jag rlimit_nofile och minneskvoter med realistiska reserver. För CPU-krävande krypteringsalgoritmer lönar det sig att testa med affinitet och modern kryptografisk acceleration.
Övervakbarhet: Status, loggar och mätvärden
Jag skapar öppenhet med en smidig Status-Endpoint (t.ex. stub_status) för att se aktiva anslutningar, läsning/skrivning/vänteläge och godkända förfrågningar. I loggarna försöker jag minimera bruset: En kompakt log_format med tid, status, uppströms-tider och byte räcker för de flesta analyser. Vid mycket hög QPS inaktiverar jag åtkomstloggen selektivt (platsbaserat) eller buffrar loggarna asynkront så att I/O inte bromsar. Fel-loggen ställer jag in på varna eller . fel och byt endast tillfälligt till felsökning. Jag korrelerar löpande latenser (median/95:e/99:e percentilen), öppna anslutningar, felprocent i backend och CPU-belastning per arbetare – utifrån detta fastställer jag justeringar av de tre nyckeldirektiven och upptäcker mättnadseffekter i ett tidigt skede.
Containrar och virtuella miljöer: Överföra gränser på ett smidigt sätt
Jag kontrollerar i containrarna de cgroup-Ange gränsvärden för CPU, RAM och PID:er och anpassa dem efter NGINX-inställningarna. ulimit -n måste vara tillräckligt högt inom containern, annars blir mina justeringar av rlimit_nofile verkningslösa. Vid CPU-kvoter (t.ex. 2 vCPU:er) ställer jag in arbetare_processer i enlighet med detta, så att schemaläggningen inte skapar onödig trängsel. När jag är nära nätverket drar jag nytta av lägre overhead-latens i „host“-nätverkslägen, medan överlagringar innebär ytterligare hopp. På Multi-NUMA-värdar är jag noga med affinitet och minnesocklar så att arbetare inte arbetar tvärs över noder. Detsamma gäller för IRQ- och RPS/XPS-affinitet: om vägarna från nätverkskortet via IRQ till arbetarkärnan stämmer, minskar latensspikarna märkbart.
Anslutningens livscykel: kortlivade portar, TIME_WAIT och reserver
Jag planerar tillräckligt tillfälliga portar (ip_local_port_range) när NGINX fungerar som aktiv klient gentemot uppströms-servrarna. Vid mycket hög anslutningsgenomströmning undviker jag överdriven portfluktuation med uppströms-keepalive, vilket minskar TIME_WAIT-köerna. Jag använder endast med försiktighet kernel-toggles för „Reuse“; moderna stackar optimerar redan mycket internt. Det är stabilare att styra anslutningarnas livslängd genom lämpliga Keepalive- och timeout-värden och återanvända för att säkerställa en rättvis fördelning. Vid kapacitetsberäkningen tar jag alltid hänsyn till uppströmsdelen utöver klienterna – ofta är det FD:erna där som utgör den egentliga begränsande faktorn, inte frontdoor.
Smidiga omstartar och driftsättningar utan avbrott
Jag använder master/worker-modellen för smidiga omladdningar: Master-noden laddar in nya konfigurationer, gamla arbetare stängs av medan nya smidigt tar över. Med timeout för avstängning av arbetare låter jag förfrågningarna avslutas ordentligt utan att blockera resurser. Jag kopplar ihop driftsättningar utan driftstopp på uppströms med hälsokontroller och proxy_next_upstream-Regler för att förhindra att enskilda felaktiga backend-komponenter ökar den globala latensen. När jag gör konfigurationsändringar ändrar jag alltid bara en inställning i taget och verifierar effekterna i loggar och mätvärden – på så sätt undviker jag misstag som beror på förvirring och säkerställer att prestandan är reproducerbar.
Kortfattad sammanfattning
Jag kopplar ihop arbetare_processer Ställ in antalet kärnor (helst automatiskt), anpassa worker_connections efter toppbelastningen och höj rlimit_nofile samt operativsystemets gränsvärden generöst. I Events-blocket använder jag epoll och multi_accept, testar allt med reproducerbara belastningstester och justerar sedan i små steg. För proxy-arbetsbelastningar räknar jag in ytterligare deskriptorer och testar CPU-affinitet när arbetsbelastningarna är konstanta. En korrekt konfigurerad stack med lämplig kärna, snabb I/O och väl valda nätverksparametrar gör hela skillnaden. Så här gör jag NGINX tillförlitligt inom det prestandaområde som krävande webbsidor och API:er behöver.
