Nginx worker_connections"imposta il numero massimo di connessioni simultanee che possono essere aperte da un processo di lavoro. Questo numero include tutte le connessioni (ad esempio connessioni con server proxy, tra le altre), non solo connessioni con i client. Un'altra considerazione è che il numero effettivo di connessioni simultanee non può superare l'attuale limite per il numero massimo di file aperti ". Ho alcune domande su questo:

1. Quale dovrebbe essere il valore ottimale o raccomandato per questo?
2. Quali sono gli svantaggi dell'utilizzo di un numero elevato di connessioni di lavoro?

Prendiamo l'approccio pragmatico.

Tutti questi limiti sono elementi hardcoded e progettati nel secolo scorso quando l'hardware era lento e costoso. Siamo nel 2016 ora, un tostapane wall-mart medio può elaborare più richieste rispetto ai valori predefiniti.

Le impostazioni predefinite sono in realtà pericolose. Avere centinaia di utenti su un sito Web non è niente di impressionante.

worker_process

Un'impostazione correlata, spiegiamola mentre siamo sull'argomento.

nginx come bilanciamento del carico:

• 1 lavoratore per il bilanciamento del carico HTTP.
• 1 lavoratore per core per il bilanciamento del carico HTTPS.

nginx come server web:

Questo è difficile.

Alcune applicazioni / framework / middleware (ad esempio php-fpm) vengono eseguiti al di fuori di nginx. In tal caso, 1 lavoratore nginx è sufficiente perché di solito è l'applicazione esterna che sta elaborando e consumando le risorse.

Inoltre, alcune applicazioni / framework / middleware possono elaborare solo una richiesta alla volta ed è inutile sovraccaricarle.

In generale, 1 lavoratore è sempre una scommessa sicura.

Altrimenti, puoi mettere un lavoratore per core se sai cosa stai facendo. Considererei tale percorso come un'ottimizzazione e consiglierei benchmarking e test adeguati.

worker_connections

La quantità totale di connessioni è worker_process * worker_connections. Metà in modalità bilanciamento del carico.

Ora stiamo raggiungendo la parte del tostapane. Esistono molti limiti di sistema sottovalutati:

• ulimits è 1k max di file aperti per processo su linux (1k soft, 4k hard su alcune distro)
• i limiti di sistema sono quasi gli stessi di ulimits.
• L'impostazione predefinita di nginx è 512 connessioni per lavoratore.
• Potrebbero essercene di più: SELinux, sysctl, supervisord (ogni versione di distro + è leggermente diversa)

1k worker_connections

L'impostazione predefinita è mettere 1k ovunque.

È abbastanza alto da essere più di quanto la maggior parte dei siti interni e sconosciuti abbia mai incontrato. È abbastanza basso da non superare altri limiti di sistema.

10k worker_connections

È molto comune avere migliaia di clienti, soprattutto per un sito Web pubblico. Ho smesso di contare la quantità di siti Web che ho visto andare giù a causa delle basse impostazioni predefinite.

Il minimo accettabile per la produzione è 10k. I limiti di sistema correlati devono essere aumentati per consentirlo.

Non esiste un limite troppo alto (un limite non ha alcun effetto se non ci sono utenti). Tuttavia, un limite troppo basso è una cosa molto reale che si traduce in utenti rifiutati e in un sito morto.

Più di 10k

10k è facile e facile.

Potremmo stabilire un limite arbitrario di 1000kk (dopo tutto è solo un limite) ma non ha molto senso pratico, non otteniamo mai quel traffico e non potremmo comunque accettarlo.

Atteniamoci a 10k come impostazione ragionevole. I servizi che stanno andando (e possono davvero fare) di più richiederanno una messa a punto e un benchmarking speciali.

Scenario speciale: utilizzo avanzato

A volte sappiamo che il server non ha molte risorse e ci aspettiamo picchi di cui non possiamo fare molto. Preferiamo rifiutare gli utenti piuttosto che provare. In tal caso, inserisci un limite di connessione ragionevole e configura i messaggi di errore e la gestione corretti.

A volte, i server back-end funzionano bene e bene, ma solo fino a un certo carico , niente di più e tutto va rapidamente a sud. Preferiremmo rallentare piuttosto che far crashare i server. In tal caso, configurare l'accodamento con limiti rigorosi, lasciare che nginx tamponi tutto il calore mentre le richieste vengono scaricate a un ritmo limitato.

ulimit -a ti dirà quanti file aperti il ​​tuo sistema consente a un processo di utilizzare.

Inoltre, net.ipv4.ip_local_port_rangeimposta la gamma totale di socket da abilitare per IP.

Quindi, il tuo worker_connectionsnon può essere più di nessuno di questi, o le tue connessioni client saranno in coda fino a quando net.core.netdev_max_backlog- le dimensioni totali della coda TCP.

Tieni presente che se stai utilizzando nginx come proxy inverso, che utilizza due socket per connessione. Potresti voler giocare un po 'con net.ipv4.tcp_fin_timeoute altri timeout relativi al kernel tcp per provare a cambiare rapidamente lo stato dei socket. Un'altra cosa da notare è che ogni socket alloca la memoria dello stack di memoria TCP, è inoltre possibile impostare alcuni limiti dello stack di memoria TCP utilizzando sysctl, è possibile esercitare maggiore pressione nella RAM purché si disponga di CPU e gestori di file sufficienti.

Cordiali saluti, è possibile disporre di risorse di elaborazione sufficienti, avere un server con circa 32 GB di RAM e alcune interfacce di rete virtuale per gestire connessioni simultanee da 1 MM con alcune ottimizzazioni del kernel tramite sysctl. Durante i miei test quando ho a che fare con più di 1 MM e l'invio di un payload di circa 700 Bit il server impiegava circa 10 secondi per aggiornare circa client simultanei di 1,2 MM. Il prossimo è stato quello di aumentare la larghezza di banda della rete collegando alcune schede di rete aggiuntive e abbandonando le reti virtuali. È possibile ottenere una pseudo comunicazione quasi in tempo reale con più di 1,2 MM client, dato il payload, la larghezza di banda e il tempo ragionevole per aggiornare tutti i client.

Buona messa a punto!

Il dimensionamento appropriato può essere scoperto attraverso i test, poiché è variabile in base al tipo di traffico gestito da Nginx.

Teoricamente, nginx può gestire: max client = worker_processes * worker_connections (* = moltiplicare) e worker_processes = numero di processori

Per scoprire i processori, utilizzare: grep processor / proc / cpuinfo | wc -l

L'impostazione di limiti inferiori può essere utile quando si è limitati alle risorse. Alcune connessioni, ad esempio, connessioni keep-alive (non solo con i client, ma anche con i server upstream ), stanno effettivamente sprecando le tue risorse (anche se nginx è molto efficiente, che lo è), e non sono necessarie per il corretto funzionamento di un server per uso generico, il che significa che possono essere rilasciati in modo sicuro per rendere disponibili più risorse per il resto dell'operazione.

Avere un limite di risorse più basso indicherebbe quindi a nginx che potresti essere a corto di risorse fisiche, e quelle disponibili dovrebbero essere allocate a nuove connessioni, piuttosto che servire le connessioni keep-alive inattive a spese delle connessioni più recenti che hanno difficoltà a essere stabilite soddisfare le esigenze più urgenti.

Qual è il valore raccomandato? È l'impostazione predefinita.

I valori predefiniti sono tutti documentati nella documentazione:

Predefinito: worker_connections 512;

E può essere confermata a livello di codice sorgente aevent/ngx_event.c , troppo

13 # definisci DEFAULT_CONNECTIONS 512

La risposta di Marcel deve davvero essere votata! Se gli ulimits sono impostati su un valore predefinito di circa 1k, max_connections dovrebbe essere impostato sullo stesso valore, altrimenti non è vantaggioso impostare max_connections su 10k.

Riceverai richieste in coda e socket chiusi su nginx se "i tuoi worker_connections non possono essere più di nessuno di questi, o le tue connessioni client faranno la coda fino a net.core.netdev_max_backlog - la dimensione totale della coda TCP."

Un singolo processo può aprirsi come può essere la connessione come gli ulimits lo consentono. num_workers * max_connections è la formula, ma è necessario tenere conto delle connessioni esterne al loadbalancer / proxy max e degli ulimits per valori ragionevoli. L'impostazione di max_connection su un valore molto alto può ritorcersi contro poiché le ulimits saranno un fattore limitante.