NGINX w dockerze przestaje odpowiadać po teście wydajnościowym

Cześć, chciałem sprawdzić sobie ile moja konfiguracja uciągnie RPS (request per seconds). Niestety mam problem z nginx w dockerze. Przy około 20 RPS nginx (lub docker? nie wiem jak to zdebugować) odmawia interakcji (wchodząc na localhost:8006 nie dostaję nawet 500, a w logach access.log/error.log nic się nie pojawia (w aktualnej konfiguracji to wyłączyłem bo myślałem, że zapychanie logów może być przyczyną gdy wyświetlają się na konsoli w dockerze)

Moja konfiguracja:
WSL i docker + docker-compose w WSL.

Pliki:
compose/nginx/DockerFile

FROM nginx:1.25
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d

compose/nginx/nginx.conf

server {
    listen 80;
    access_log  off;
    error_log  off;
}

docker-compose.yml

version: '3.3'

services:
  nginx:
    build: ./compose/nginx
    ports:
      - 8006:80

Po odpaleniu docker-compose up dostaję normalne odpowiedzi od nginx (pod adresem http://localhost:8006/).
Jednak gdy odpalam stress testing w pewnym momencie (około 20 RPS co jest śmieszna liczbą jak na samego nginx gdzie wykluczyłem tutaj inne rzeczy) nginx przestaje odpowiadać.

Gdy wyłącze stress testing (korzystam z Locust) to nginx nadal nie odpowiada ale wciąż działa (docker-compose ps pokazuje uruchomionego) oraz mogę podłączyć się do niego docker-compose exec nginx bash

Nie jestem w stanie namierzyć przyczyny, czy byłby ktoś w stanie mi pomóc?

Uruchomienie tego w WSLu, to już jest performance stress sam w sobie :-)

Możesz sobie odpalić basha w kontenerze i tam taki prosty snippet:

while true; do ss -s ; sleep 1;  done

Co sekundę będzie pokazywał Ci statystyki socketów w formie:

Total: 203
TCP:   25 (estab 10, closed 1, orphaned 0, timewait 1)

Transport Total     IP        IPv6
RAW       1         0         1
UDP       9         6         3
TCP       24        22        2
INET      34        28        6
FRAG      0         0         0

Może to pokaże czy jakiekolwiek sockety są tworzone wewnątrz kontenera i czy są zamykane. Pomijając WLSa, to może jakiś limit zostaje wyczerapny, np. max ilość otwartych plików.

yarel napisał(a):

Uruchomienie tego w WSLu, to już jest performance stress sam w sobie :-)

Niby tak :D Ale jak odpalałem test pomijając nginx to stabilność była przy większych RPS

yarel napisał(a):

Może to pokaże czy jakiekolwiek sockety są tworzone wewnątrz kontenera i czy są zamykane. Pomijając WLSa, to może jakiś limit zostaje wyczerapny, np. max ilość otwartych plików.

Załączam screen. To z góry jest z czasów jak działa a to z dołu jak przestało działać. Wydaję mi się, że nginx by zwracał błąd jeśli chodzi o max otwartą ilość plików (przynajmniej z tego co widziałem jak szukałem rozwiązania) i chyba przy takich małych liczbach to nie powinno być problemem

Cóż, z innych pomysłów pozwalających zawęzić nieco obszar analizy, to dodanie w iptables logowania pakietów przychodzących na port 80. Możesz w ten sposób sprawdzić, czy w momencie gdy nginx przestaje odpowiadać, jakikolwiek ruch przychodzi na port 80 interfejsu w kontenerze. Jeśli ruch nie przychodzi, a jest generowany z Locusta, to problemem nie będzie z nginxem, a będzie gdzieś pomiędzy locustem a Dockerem.

Tu masz jak włączać logowanie pakietów:

• https://tecadmin.net/enable-logging-in-iptables-on-linux/
• https://www.baeldung.com/linux/iptables-log-separate-file

Później możesz sobie sprawdzić w logach kiedy przyszedł ostatni pakiet na port 80 i jak się to ma do momentu, w którym przestałeś dostawać wiadomości.
Używając /var/log/* albo jounalctl

Od strony Windowsa też możesz patrzeć na sieć za pomocą netstata, czy nie pojawiły Ci się jakieś waity.

netstat -an | findstr "127.0.0.1"

Zainteresuj się dyrektywami Nginx-a worker_processes i worker_connections

max clients = worker_processes * worker_connections

https://nginx.org/en/docs/ngx_core_module.html