Ich betreibe eine Drupal 7-Anwendung (3 Backends) und habe 3 Varnish-Server, die sich ständig weigern, das Backend abzurufen. Ich habe hier viele ähnliche Fehler gelesen, kann mein Problem aber immer noch nicht lösen, es kommt die Meldung 503 Varnish Fetch Failed Guru Meditation. Ich habe alle Beiträge hier gelesen und alle schienen ein hohes Timeout zu empfehlen, ich habe es auf 600 s eingestellt und viele empfehlen .probe nicht, ich habe Round.Robin (Wechsel des Backends) und hier ist meine Backend-Konfiguration:
backend project1 {
.host = "myhost.ip";
.port = "80";
.connect_timeout = 600s;
.first_byte_timeout = 600s;
.probe = {
.timeout = 600s;
.interval = 10s;
.window = 5;
.threshold = 2;
.request =
"GET HTTP/1.1"
"Host: example.com"
"Connection: close";
}
}
ich habe übrigens mein Fehlerprotokoll und mein Zugriffsprotokoll überwacht und mir ist aufgefallen, dass ich zu viele Fehler dieser Art habe, aber ich möchte nicht, dass Sie voreingenommen sind.
[info] Client prematurely closed connection (broken pipe)
und manchmal
reqv failed
Als Randbemerkung möchte ich auch erwähnen, dass bei mir immer noch ein Fast-CGI-Fehler auftritt, aber ich glaube nicht, dass er etwas mit meinem Varnish-Fehler zu tun hat:
Primary Script unknown ......, fastcgi, upstream:127.0.0.1
ich führe nginx+php-fpm über Fast-CGI aus. Ich bin mir wirklich nicht sicher, welche Konfiguration Varnish vom Backend erwartet, sodass es sich weigert, sie abzurufen.
Es ist schon einmal vorgekommen, dass eine falsche Nginx-Konfiguration diesen Fehler verursacht hat, also hier meine Nginx-Konfiguration:
user nginx nginx;
worker_processes 4;
error_log /var/log/nginx/error.log info;
events {
worker_connections 8192;
multi_accept on;
use epoll;
}
worker_rlimit_nofile 64000;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main
'$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" ';
client_header_timeout 10m;
client_max_body_size 100m;
client_body_timeout 10m;
send_timeout 10m;
client_body_buffer_size 3m;
connection_pool_size 256;
client_header_buffer_size 1k;
large_client_header_buffers 4 2k;
request_pool_size 32k;
gzip on;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/xml;
open_file_cache max=2000 inactive=20s;
open_file_cache_valid 60s;
open_file_cache_min_uses 5;
open_file_cache_errors off;
output_buffers 1 32k;
postpone_output 1460;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
fastcgi_send_timeout 1800;
fastcgi_read_timeout 1800;
fastcgi_connect_timeout 1800;
fastcgi_ignore_client_abort on;
keepalive_timeout 75 20;
ignore_invalid_headers on;
index index.html;
server {
listen 80;
server_name example.com;
rewrite ^(.*) http://example.com$1 permanent;
}
server {
listen 80;
server_name www.example.com;
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log info;
root /var/www/public;
index index.php index.phtml index.html;
autoindex on;
gzip_types text/plain text/css application/json application/x-ja
vascript text/xml application/xml application/xml+rss text/javascript applicatio
n/javascript;
location ~ \..*/*\.php$ {
return 403;
}
location ~^/sites/.*/private/{
return 403;
}
location ~^/sites/.*/files/* {
try_files $uri @rewrite;
}
location ~ (^|/)\. {
return 403;
}
location / {
try_files $uri @rewrite;
}
location @rewrite {
rewrite ^ /index.php;
}
location ~ \.php$ {
try_files $uri @rewrite;
#fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_keep_conn off;
include /etc/nginx/fastcgi_params;
}
location ~* \.(jpg|jpeg|css|gif|png|js|ico|xml)$ {
try_files $uri $uri/ ;
access_log off;
log_not_found off;
expires 30d;
}
}
Kann mir jemand sagen, wie ich dieses Problem beheben kann? Ich bin mir wahrscheinlich sicher, dass pb auf meinem Backend und nicht auf meinem Varnish liegt, bin mir aber nicht sicher, warum die Website manchmal geladen wird und manchmal direkt die schreckliche Meldung „Backend-Abruf fehlgeschlagen 503 – Guru-Meditation“ ausgibt. Danke für Ihre wertvolle Hilfe.
AKTUALISIEREN:
Die Lösung bestand darin, gzip zu deaktivieren. Ich hatte einen leeren Inhalt und eine Weiterleitung auf der Homepage, also löste gzip+header-content-length=0 (leer) eine rote Flagge bei Varnish aus, Varnish kennzeichnete es als nicht fehlerfrei, etwas mit der Größe 0 zu komprimieren. Falscher Header. Entweder gzip deaktivieren oder etwas Inhalt an die Serverantwort zurückgeben würde dieses Problem beheben
Antwort1
In Ihrem Fall .requesthaben Sie anscheinend kein Dokument angegeben. Ich gehe davon aus, dass es daher versucht, Ihre gesamte Drupal-Site als Probe zu laden. Sie könnten dies wie folgt ändern:
"GET /sitehealth.html HTTP/1.1"
Dabei sitehealth.htmlhandelt es sich lediglich um eine einfache Textdatei, die die Sonde laden kann.
Weitere Fehlerbehebung: Können Sie die Sonden vollständig deaktivieren und prüfen, ob das einen Unterschied macht? Erhalten Sie Fehlermeldungen, wenn Sie die Website direkt aufrufen, ohne den Cache zu verwenden?
Entscheiden Sie sich grundsätzlich für die einfachste Konfiguration, die zuverlässig funktioniert, und fügen Sie dann nach und nach Ihre zusätzlichen Funktionen hinzu, bis Sie auf etwas stoßen, das nicht mehr funktioniert.