nginx php5-fpm upstream timed out (110: время ожидания соединения) при подключении к upstream
у нас есть веб-сервер, работающий с настройкой 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
сервер не был загружен, когда произошла ошибка, и загрузка avg была всего 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
1 ответов
во-первых, уменьшите PHP-FPM max_requests
до 100; вы хотите, чтобы PHP-потоки перезапускались намного раньше, чем 10000 req.
во-вторых, у вас есть только один процесс PHP работает с большим количеством детей. Это хорошо для разработки, но в производстве вы хотите иметь больше PHP-процессов с меньшим количеством детей, так что если этот процесс идет вниз по какой-либо причине, есть другие, которые могут занять слабину. Таким образом, вместо соотношения 1:50, как у вас сейчас, перейдите к соотношению 10:5. Это будет много более стабильный.
для достижения этого вы можете посмотреть на что-то вроде руководитель для управления процессами PHP. Мы используем это в производстве, и это действительно помогло увеличить наше время безотказной работы и уменьшить количество времени, которое мы тратим на управление/мониторинг серверов. Вот пример нашего config:
/ 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
/и т. д./nginx/conf/и РНР.бэкэнд:
upstream backend {
server unix:/tmp/php.socket
}
EDIT:
как и все настройки сервера, не полагайтесь на догадки, чтобы отслеживать, где ваши проблемы. Я рекомендую установить Munin вместе с различными плагинами PHP(-FPM) и nginx; они помогут вам отслеживать жесткую статистику запросы, время отклика, использование памяти, доступ к диску, уровни потока/процесса... все важно при отслеживании, где проблемы.
кроме того, как я уже упоминал в комментарии ниже, добавление как серверного, так и клиентского кэширования в вашу настройку, даже на скромном уровне, может помочь в обеспечении лучшего опыта для пользователей, будь то использование собственной поддержки кэширования nginx или что - то более конкретное, например, varnishd. Даже самые динамичные сайты / приложения имеют много статических элементов, которые может храниться в памяти и обслуживаться быстрее. Обслуживание их из кэша может помочь уменьшить нагрузку в целом и гарантировать, что те элементы, которые абсолютно должны быть динамическими, имеют все необходимые им ресурсы, когда они в них нуждаются.