☰

Die Upstream-Antwortzeit von Nginx ist gelegentlich sehr langsam

tag-icon • tag-icon nginx load-balancing
Die Upstream-Antwortzeit von Nginx ist gelegentlich sehr langsam

Ich habe einen Ubuntu-Server, der sehr viel Datenverkehr und sehr viele Sites bewältigt. Gelegentlich braucht Nginx sehr lange, um zu antworten (manchmal 20 bis 30 Sekunden, und normalerweise läuft die Anforderung vorher ab). Zunächst dachte ich, es läge an Datenverkehrsspitzen in Kombination damit, dass Passenger damit nicht gut zurechtkommt. Inzwischen habe ich Passenger aber durch Puma ersetzt und einen Lastenausgleich für den Datenverkehr durchgeführt, und das Problem tritt immer noch auf.

Nginx Amplify sendet mir Warnungen, dass der Typ nginx.upstream.response.timezu hoch ist, beispielsweise 14 Sekunden.

Hier ist ein allgemeiner Überblick über das Setup:

  • Server Nr. 1 (der mit der gelegentlich langsamen Reaktion) hat Nginx-Serverblöcke für über 300 Sites.
  • der Server blockiert proxy_passeinen Load Balancer-Serverblock (sites.myapp.com) auch auf Server Nr. 1
  • Der Load Balancer teilt den Datenverkehr zwischen diesem Server Nr. 1 (Gewicht 1) und Server Nr. 2 (Gewicht 2) auf, so dass die doppelte Menge an Datenverkehr an Server Nr. 2 geht
  • Sowohl auf Server Nr. 1 als auch auf Server Nr. 2 habe ich einen weiteren Serverblock, der den Datenverkehr vom Load Balancer empfängt und proxy_passan einen von Puma verwendeten Unix-Socket weiterleitet, um eine Instanz meiner App bereitzustellen.

Die entsprechenden Konfigurationen dazu finden Sie weiter unten. Ich weiß nicht, wie ich das Problem beheben kann, aber ich frage mich, ob es in diesen Serverblöcken vielleicht einige Konfigurationen gibt, die verbessert werden können, wie zum Beispiel das Deaktivieren der Proxy-Pufferung oder das Ändern der Proxy-Puffergröße?

Irgendeine Idee, was die Ursache sein könnte und wie man das Problem aufspürt? Denn wenn Nginx sehr langsam reagiert, wird der Datenverkehr nicht einmal auf Server 2 umgeleitet.

Beachten Sie, dass ich weiß, dass ich alle Site-Serverblöcke/SSLs und den Load Balancer auf einen separaten Server verschieben sollte, damit zumindest während der langsamen Reaktionsphase von Server 1 der Datenverkehr immer noch an Server 2 weitergeleitet wird, aber derzeit habe ich nur diese beiden Server.

Beispiel einer Site-Konfiguration:

server {
  server_name www.somesite.com;

  location / {
    proxy_pass                      https://sites.myapp.com;
    proxy_set_header                X-Real-IP       $remote_addr;
    proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header                Cookie $http_cookie;
    proxy_set_header                WLDOMAIN www.somesite.com;
    proxy_cookie_domain             .myapp.com .somesite.com;
    proxy_pass_request_headers      on;
    rewrite ^/(.*)$ /sites/12345/$1 break;
  }
}

Vereinfachte Konfiguration des Load Balancers:


upstream cluster {
  ip_hash;
  server X.X.X.X:1234 weight=1; #internal ip of server #1
  server Y.Y.Y.Y:1234 weight=2; #internal ip of server #2
}

server {
  server_name sites.myapp.com;
  
  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://cluster;

    proxy_next_upstream error timeout invalid_header http_429 http_500 http_502 http_503 http_504;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    proxy_redirect off;
  }
}

Vereinfachte Upstream-Konfiguration:

upstream puma {
  server unix:///var/www/myapp/shared/sockets/puma.sock;
}

server {
  listen 1234;

  root /var/www/myapp/public;

  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://puma;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    proxy_redirect off;
  }

}

Beachten Sie, dass dieses Problem bereits auftrat, als das Setup nur darin bestand, dass die Server der verschiedenen Sites proxy_passden Datenverkehr zu einem Upstream blockierten, anstatt den Load Balancer dazwischen zu haben und die App von Passenger statt von Puma bereitgestellt zu bekommen.

Falls es wichtig ist: Die App ist Ruby on Rails.

Antwort1

Nachdem ich die Debug-Ausgabe in Nginx aktiviert hatte, schien das Problem beim Nchan-Modul im nginx-extrasPaket von Phusion Passenger zu liegen. Dieses ist fehlerhaft und bleibt ab und zu hängen. Nachdem ich Passenger entfernt (durch Puma ersetzt) ​​und nginx-extrasdurch ersetzt hatte nginx, hatte ich dieses Problem seitdem nicht mehr.

verwandte Informationen