Выборка бэкенда перестала работать - выборка привычки лака drupal бэкенд

Я выполняю приложение (3backends) drupal 7, и у меня есть 3 сервера лака, непрерывно отклоняющие для выборки бэкенда. Я считал многих подобная ошибка здесь, но все еще наклон решает мою проблему, бросание 503 выборок лака привело медитацию гуру к сбою. Я прочитал все сообщения здесь, и все, казалось, рекомендовали высокий тайм-аут, я установил на 600 с, и многие не рекомендуют .probe, у меня есть round.robin (переключающий бэкенд), и вот моя конфигурация бэкенда:

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";
}
}

я контролировал свой журнал ошибок и журнал доступа, между прочим и я заметил, что у меня есть слишком много ошибки как это, но я не хочу, чтобы Вы были смещены.

[info] Client prematurely closed connection (broken pipe)

и иногда

reqv failed

Как заметка на полях, которую я хочу к mentionalso, у меня есть быстрая-cgi ошибка, все еще продолжающаяся, но я не думаю, что это имеет отношения с моей ошибкой лака:

Primary Script unknown  ......, fastcgi, upstream:127.0.0.1

я работаю nginx+php-fpm через быстро-cgi. я действительно не уверен, что лак конфигурации ожидает от бэкенда, которые заставляют его отказаться выбирать его,

Это произошло, что несправедливость nginx конфигурация дала мне эту ошибку прежде, таким образом, вот моя конфигурация nginx:

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;
                    }

}

Кто-то может указать на меня который направление отладить эту проблему? я, вероятно, уверен, свинец находится на моем бэкенде, а не моем лаке, но не уверенный, почему веб-сайт иногда загружается и иногда бросает straight/awfull, "выборка бэкенда перестала работать 503 - медитация гуру". спасибо за Вашу драгоценную справку.

ОБНОВЛЕНИЕ:

фиксация должна была отключить gzip. У меня были пустое содержание и перенаправление на домашней странице, таким образом, gzip + header-content-length=0 (пустой) инициировал красный флаг, чтобы лакировать, лакировать маркированный как вредный для здоровья для сжатия чего-то с размером 0. Неправильный заголовок. или отключите gzip или возвратитесь, некоторое содержание к ответу сервера устранило бы эту проблему

2
задан 15 January 2016 в 07:42
1 ответ

В вашем .запросе вы, кажется, не указали документ. Поэтому я предполагаю, что он пытается загрузить весь ваш сайт Drupal как зонд. Вы можете изменить это на:

"GET /sitehealth.html HTTP/1.1"

где sitehealth.html - это простой текстовый файл, который зонд может загрузить.

Дальнейшее устранение неисправностей, можете ли вы полностью отключить зонды и посмотреть, имеет ли это значение? Вы получаете какие-нибудь ошибки при прямом попадании на сайт, не проходя через кэш?

В основном, получите самую простую конфигурацию, которая надежно работает, а затем добавляйте свои дополнительные функции по очереди, пока не ударите по чему-нибудь, что сломается.

1
ответ дан 3 December 2019 в 12:44

Теги

Похожие вопросы