Nginx worker_connections"ustawia maksymalną liczbę równoczesnych połączeń, które można otworzyć w procesie roboczym. Liczba ta obejmuje wszystkie połączenia (np. Połączenia z serwerami proxy), nie tylko połączenia z klientami. Inną kwestią jest to, że rzeczywista liczba jednoczesnych połączeń nie może przekroczyć aktualnego limitu maksymalnej liczby otwartych plików ". Mam kilka pytań na ten temat:

1. Jaka powinna być dla tego optymalna lub zalecana wartość?
2. Jakie są wady używania dużej liczby połączeń roboczych?

Przyjmijmy pragmatyczne podejście.

Wszystkie te ograniczenia to rzeczy, które zostały zakodowane na stałe i zaprojektowane w ubiegłym wieku, kiedy sprzęt był wolny i drogi. Jesteśmy w 2016 roku, przeciętny toster ścienny może przetworzyć więcej żądań niż wartości domyślne.

Domyślne ustawienia są w rzeczywistości niebezpieczne. Posiadanie setek użytkowników na stronie internetowej nie jest imponujące.

proces_procesowy

Powiązane ustawienie, wyjaśnijmy to, gdy jesteśmy w temacie.

nginx jako moduł równoważenia obciążenia:

• 1 pracownik do równoważenia obciążenia HTTP.
• 1 pracownik na rdzeń do równoważenia obciążenia HTTPS.

nginx jako serwery WWW:

Ten jest trudny.

Niektóre aplikacje / frameworki / oprogramowanie pośrednie (np. Php-fpm) są uruchamiane poza Nginx. W takim przypadku wystarczy 1 pracownika nginx, ponieważ zwykle jest to zewnętrzna aplikacja, która intensywnie przetwarza i zjada zasoby.

Ponadto niektóre aplikacje / frameworki / oprogramowanie pośrednie mogą przetwarzać tylko jedno żądanie na raz i przeciążenie ich jest wsteczne.

Ogólnie rzecz biorąc, 1 pracownik jest zawsze bezpiecznym zakładem.

W przeciwnym razie możesz umieścić jednego pracownika na rdzeń, jeśli wiesz, co robisz. Uważam tę drogę za optymalizację i doradzam odpowiednie testy porównawcze i testy.

połączenia_procesowe

Łączna liczba połączeń wynosi worker_process * worker_connections. Połowa w trybie równoważenia obciążenia.

Teraz dochodzimy do części tostera. Istnieje wiele poważnie niedocenianych limitów systemu:

• ulimits to maksymalnie 1k otwartych plików na proces w systemie Linux (1k miękki, 4k twardy w niektórych dystrybucjach)
• systemed limity są mniej więcej takie same jak ulimits.
• Domyślnie nginx to 512 połączeń na pracownika.
• Może być więcej: SELinux, sysctl, supervisord (każda wersja distro + jest nieco inna)

1k połączeń_obsługowych

Domyślnym bezpiecznym rozwiązaniem jest umieszczenie 1k wszędzie.

Jest wystarczająco wysoki, aby był większy niż większość wewnętrznych i nieznanych stron kiedykolwiek się z nim spotka. Jest wystarczająco niski, aby nie przekroczyć żadnych innych limitów systemu.

10k połączeń_obsługowych

Bardzo często mamy tysiące klientów, szczególnie w przypadku publicznej witryny internetowej. Przestałem zliczać liczbę stron, które widziałem, które spadły z powodu niskich domyślnych ustawień.

Minimalne dopuszczalne do produkcji to 10 tys. Powiązane limity systemowe muszą zostać zwiększone, aby na to pozwolić.

Nie ma czegoś takiego jak zbyt wysoki limit (limit po prostu nie działa, jeśli nie ma użytkowników). Jednak zbyt niski limit to bardzo realna rzecz, która powoduje odrzucenie użytkowników i martwą witrynę.

Ponad 10 tys

10k jest przyjemne i łatwe.

Moglibyśmy ustalić dowolne limity 1000kk (w końcu to tylko limit), ale to nie ma praktycznego sensu, nigdy nie uzyskujemy tego ruchu i nie mogliśmy go znieść.

Trzymajmy się 10k jako rozsądnego ustawienia. Usługi, które będą (i naprawdę mogą zrobić) więcej, będą wymagać specjalnego strojenia i testów porównawczych.

Scenariusz specjalny: użycie zaawansowane

Czasami wiemy, że serwer nie ma wielu zasobów i oczekujemy skoków, o których niewiele możemy zrobić. Wolimy odmawiać użytkownikom niż próbować. W takim przypadku ustal rozsądny limit połączenia i skonfiguruj ładne komunikaty o błędach i obsługę.

Czasami serwery zaplecza działają dobrze i dobrze, ale tylko do pewnego obciążenia , cokolwiek więcej i wszystko idzie szybko na południe. Wolelibyśmy zwolnić, niż spowodować awarię serwerów. W takim przypadku skonfiguruj kolejkowanie z ścisłymi limitami, pozwól nginx buforować całe ciepło, podczas gdy żądania są opróżniane w ograniczonym tempie.

ulimit -a powie Ci, ile otwartych plików Twój system zezwala na użycie procesu.

Ponadto net.ipv4.ip_local_port_rangeokreśla całkowitą gamę gniazd w celu umożliwienia za OD.

Tak więc worker_connectionsnie możesz być więcej niż którykolwiek z nich, w przeciwnym razie połączenia z klientami będą się kolejkować aż net.core.netdev_max_backlogdo całkowitego rozmiaru kolejki TCP.

Pamiętaj, że jeśli używasz nginx jako odwrotnego proxy, używa on dwóch gniazd na połączenie. Możesz zagrać trochę z net.ipv4.tcp_fin_timeoutlimitami czasu związanymi z tcp jądra, aby szybko zmienić stan gniazd. Inną rzeczą, na którą należy zwrócić uwagę, jest to, że każde gniazdo przydziela pamięć stosu pamięci TCP, możesz również ustawić pewne limity stosu pamięci TCP za pomocą sysctl, możesz wywrzeć większy nacisk na pamięć RAM, o ile masz procesor i wystarczającą liczbę programów do obsługi plików.

FYI jest możliwe, biorąc pod uwagę wystarczającą ilość zasobów obliczeniowych, aby mieć jeden serwer z około 32 GB pamięci RAM i niektóre interfejsy sieci wirtualnej do obsługi 1MM jednoczesnych połączeń z niektórymi tuningami jądra za pomocą sysctl. Podczas moich testów, gdy miałem do czynienia z ponad 1 MM i wysyłałem ładunek około 700 Bajtów, serwer potrzebował około 10 sekund na aktualizację około 1,2 MM jednoczesnych klientów. Następnie zwiększono przepustowość sieci, łącząc dodatkowe karty sieciowe i porzucając wirtualne karty sieciowe. Możliwe jest osiągnięcie pseudo-zbliżonej komunikacji w czasie rzeczywistym z ponad 1,2 mln klientów, biorąc pod uwagę ładowność, przepustowość i rozsądny czas na aktualizację wszystkich klientów.

Miłego strojenia!

Odpowiedni dobór wielkości można znaleźć poprzez testowanie, ponieważ jest on zmienny w zależności od rodzaju ruchu obsługiwanego przez Nginx.

Teoretycznie nginx może obsłużyć: max klientów = procesy_procesowe * połączenia_procesowe (* = pomnożenie) i procesy_procesowe = liczba procesorów

Aby znaleźć procesory, użyj: grep Processor / proc / cpuinfo | wc -l

Ustawienie dolnych limitów może być przydatne, gdy możesz być ograniczony zasobami. Niektóre połączenia, na przykład utrzymywanie połączeń (nie tylko z klientami, ale także z serwerami nadrzędnymi ), skutecznie marnują twoje zasoby (nawet jeśli nginx jest bardzo wydajny, i jest) i nie są wymagane do poprawne działanie serwera ogólnego przeznaczenia, co oznacza, że ​​można go bezpiecznie upuścić, aby udostępnić więcej zasobów na resztę operacji.

Niższy limit zasobów oznaczałby zatem dla Nginx, że możesz mieć mało zasobów fizycznych, a te dostępne powinny zostać przydzielone do nowych połączeń, zamiast obsługiwać bezczynne połączenia podtrzymujące koszt kosztem nowych połączeń, które mają problemy z ustanowieniem zaspokajają najbardziej palące potrzeby.

Jaka jest zalecana wartość? To jest domyślne.

Wszystkie wartości domyślne są udokumentowane w dokumentacji:

Domyślnie: worker_connections 512;

I może być potwierdzony na poziomie kodu źródłowego naevent/ngx_event.c zbyt

13 # zdefiniuj DOMYŚLNE POŁĄCZENIA 512

Odpowiedź Marcela naprawdę musi zostać oceniona! Jeśli ulimits są ustawione na domyślną wartość około 1k, max_connections powinno być ustawione wokół tej samej wartości, w przeciwnym razie ustawienie max_connections na 10k nie przyniesie korzyści.

Otrzymasz w kolejce żądanie i gniazda zamknięte w Nginx, jeśli „twoje połączenia_ robotnicze nie mogą być większe niż którekolwiek z nich, lub połączenia klientów będą się kolejkować aż do net.core.netdev_max_backlog - całkowity rozmiar kolejki TCP”.

Pojedynczy proces może zostać otwarty, podobnie jak połączenie, na jakie pozwalają limity. num_workers * max_connections to formuła, ale poza rozsądnymi wartościami należy wziąć pod uwagę maksymalne połączenia i ograniczenia maksymalnego obciążenia i ograniczenia serwera proxy. Ustawienie naprawdę wysokiej wartości parametru max_connection może się nie powieść, ponieważ ograniczniki będą stanowić ograniczenia.