nginx php5-fpm истекло по тайм-ауту (110: тайм-аут соединения) при подключении к вышестоящему

Question

У нас есть веб-сервер, работающий с настройкой nginx php5-fpm apc.Однако в последнее время мы наблюдали ошибки тайм-аута восходящего соединения и замедления при отображении страницы.Быстрый перезапуск php5-fpm решил проблему, но мы не смогли найти причину.

У нас есть другой веб-сервер, на котором запущен apache2 под другим поддоменом, который подключается к той же базе данных и выполняет ту же работу.Но замедление происходит только на сервере nginx-fpm.Я думаю, что php5-fpm или apc могут вызвать проблемы.

Журналы говорят, что различные тайм-ауты соединения:

upstream timed out (110: Connection timed out) while connecting to upstream bla bla bla

Журнал php5-fpm не показываетчто-нибудь.Просто дочерние элементы запускаются и заканчиваются:

Apr 07 22:37:27.562177 [NOTICE] [pool www] child 29122 started
Apr 07 22:41:47.962883 [NOTICE] [pool www] child 28346 exited with code 0 after 2132.076556 seconds from start
Apr 07 22:41:47.963408 [NOTICE] [pool www] child 29172 started
Apr 07 22:43:57.235164 [NOTICE] [pool www] child 28372 exited with code 0 after 2129.135717 seconds from start

Сервер не был загружен, когда произошла ошибка, а загрузка составила всего 2 (2cpus 16cores), а процессы php5-fpm работали нормально.

nginx conf:

user www-data;
worker_processes 14;
pid /var/run/nginx.pid;
# set open fd limit to 30000
worker_rlimit_nofile 30000;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

nginx с поддержкой сайта conf:

    location ~* \.php$ {
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        fastcgi_pass   backend;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_param  QUERY_STRING     $query_string;
        fastcgi_param  REQUEST_METHOD   $request_method;
        fastcgi_param  CONTENT_TYPE     $content_type;
        fastcgi_param  CONTENT_LENGTH   $content_length;
        fastcgi_intercept_errors        off;
        fastcgi_ignore_client_abort     off;
        fastcgi_connect_timeout 20;
        fastcgi_send_timeout 20;
        fastcgi_read_timeout 180;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_temp_file_write_size 256k;
    }

## Disable viewing .htaccess & .htpassword
    location ~ /\.ht {
        deny  all;
    }
}
upstream backend {
        server 127.0.0.1:9000;
}

fpm conf:

pm.max_children = 500
pm.start_servers = 100
pm.min_spare_servers = 50
pm.max_spare_servers = 100
pm.max_requests = 10000

В экстренном перезапуске есть настройкиfpm conf файлЯ не знаю, помогают ли они нам решить проблему?

emergency_restart_interval = 0

Answer 1

Во-первых, уменьшите PHP-FPM max_requests до 100;Вы хотите, чтобы потоки PHP перезапускались намного раньше, чем 10000 запросов.

Во-вторых, у вас работает только один процесс PHP с большим количеством детей.Это хорошо для разработки, но на производстве вам нужно иметь больше PHP-процессов, в каждом из которых будет меньше дочерних элементов, так что если этот процесс по какой-либо причине завершится, есть другие, которые могут восполнить провал.Таким образом, вместо соотношения 1:50, как сейчас, выберите соотношение 10: 5.Это будет намного более стабильным.

Чтобы достичь этого, вам может понадобиться что-то вроде supervisor для управления вашими процессами PHP.Мы используем это в работе, и это действительно помогло увеличить время безотказной работы и сократить время, которое мы тратим на управление / мониторинг серверов.Вот пример нашей конфигурации:

/ etc / php5 / php-fpm.conf:

[global]
daemonize = no

[www]
listen = /tmp/php.socket

/ etc / supervisor.d / php-fpm.conf:

[program:php]
user=root
command=/usr/sbin/php-fpm -c /etc/php5/php.ini -y /etc/php5/php-fpm.conf
numprocs=10
process_name=%(program_name)s

/ etc / nginx / conf / php.backend:

upstream backend {
    server unix:/tmp/php.socket
}

РЕДАКТИРОВАТЬ:

Как и во всех настройках сервера, не полагайтесь на догадки, чтобы отследить, где находятся ваши проблемы.Я рекомендую установить Munin вместе с различными плагинами PHP (-FPM) и Nginx;они помогут вам отслеживать точную статистику по запросам, времени отклика, использованию памяти, обращению к диску, уровням потоков / процессов ... все это важно при отслеживании проблем.

Кроме того, как я уже упоминал в комментарии ниже, добавление кэширования как на стороне сервера, так и на стороне клиента в настройку, даже на скромном уровне, может помочь улучшить работу пользователей, будь тоиспользуя встроенную поддержку кэширования nginx или что-то более конкретное, например, varnishd.Даже самые динамичные сайты / приложения имеют много статических элементов, которые могут храниться в памяти и обслуживаться быстрее.Обслуживание их из кэша может помочь снизить общую нагрузку и обеспечить, чтобы те элементы, которые должны быть динамичными, имели все необходимые ресурсы, когда они им нужны.