nginx php5-fpm възходящ поток изтече (110: Времето за изчакване на връзката) при свързване към възходящ поток

Имаме уеб сървър, работещ с настройка на 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 16 ядра) и изглежда, че процесите 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 активирана конфигурация на сайта:

    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

person faraklit    schedule 07.04.2011    source източник
comment
Какво ще кажете за опцията за слушане в fpm.conf? Порт за слушане 9000 ли е?   -  person CyberDem0n    schedule 08.04.2011
comment
сигурен. слушам = 127.0.0.1:9000   -  person faraklit    schedule 08.04.2011


Отговори (1)


Първо, намалете PHP-FPM max_requests до 100; искате PHP нишките да се рестартират много по-рано от 10 000 req.

Второ, имате само един 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. Дори най-динамичните сайтове/приложения имат много статични елементи, които могат да се държат в паметта и да се обслужват по-бързо. Обслужването им от кеша може да помогне за намаляване на натоварването като цяло и да гарантира, че тези елементи, които абсолютно трябва да бъдат динамични, разполагат с всички ресурси, от които се нуждаят, когато имат нужда от тях.

person Phillip B Oldham    schedule 08.04.2011
comment
Благодаря ви, ще опитам вашите предложения. Мислех, че малките max_requests ще доведат до ненужни разходи за убиване/създаване на процес. Ако създадем повече родителски php процеси и отделни php процеси, засяга ли се APC? Засега не използваме сокет, в случай че използваме друг специален сървър за обработка на php. - person faraklit; 08.04.2011
comment
Не трябва да използвате отделен сървър за обработка на PHP, ако използвате nginx+php-fpm; настройването на nginx/php и кеширането с помощта на varnishd ще бъде много по-продуктивно. PHP работи по-добре, когато е краткотраен; това е, за което е проектирано, така че рестартирането е добро нещо. APC не трябва да бъде засегнат. И не забравяйте да приемете отговора, ако е бил полезен! ;-) - person Phillip B Oldham; 11.04.2011
comment
numproc=10 10 процеса споделят един и същ APC shm? и относно проблема с tcp какво ще стане, ако се изисква да обслужва твърде много страници (10-20M на ден)? Разбира се, ще приема веднага щом опитам и това реши проблема ни. ;) - person faraklit; 12.04.2011
comment
Наистина не бих се тревожил за APC; повече процедури може да означава повече използване на mem, но това е добре, тъй като ще обслужвате повече страници успешно! Що се отнася до умирането на PHP; PHP има вграден твърд лимит от максимум 250 req. Ние открихме, че когато PHP достигне този твърд лимит, той често може да приеме reqs, докато рециклира, причинявайки тези reqs да висят/отказват. Намаляването на лимита коригира проблема, заедно с предоставянето на множество бекендове на nginx, което му позволява да премине към друг бекенд/процес, ако не получи отговор навреме. Опитай; наблюдавайте резултатите с плъгини Munin + nginx/fpm и сравнете с текущата си настройка. - person Phillip B Oldham; 12.04.2011
comment
Освен това, ако се притеснявате да обслужвате 10-20 милиона страници на ден, вие НАИСТИНА трябва да кеширате всичко, което можете, с varnishd. PHP+APC няма да се доближи до пропускателната способност, която varnish може да постигне, дори и с краткотрайно време на кеширане; уебсайтът на BBC iPlayer кешира страници за много кратко време (1-5 минути), но дори това скромно ниво на кеширане дава огромно намаляване на натоварването на техните сървъри. С умна/агресивна стратегия за кеширане можете лесно да обслужвате нивата, които споменавате, със скромна хардуерна настройка. Кеширането - това е бъдещето! - person Phillip B Oldham; 12.04.2011
comment
Това е сайт за социална мрежа и повечето от страниците са за всеки потребител и са много динамични, което трябва винаги да се актуализира. Кешираме всички общи страници. Уеб сървърите не са прекалено натоварени дори в пиковите часове. fpm и apc кеширането на опкод работи добре за нас за момента, но закачанията са досадни. - person faraklit; 12.04.2011
comment
Дори кеширането на потребителска страница за 1 минута ще ви помогне да видите намаляване на натоварването на вашия сървър и вашите потребители няма да забележат остарялото съдържание, ако поемете примера на FB и използвате относителни времеви отпечатъци (напр. преди около 3 минути), изчислени от страна на клиента с JS . Независимо от това, както увеличаването, така и след това наблюдението на вашите php процеси ще ви помогне да проследите и премахнете всички тесни места. - person Phillip B Oldham; 12.04.2011
comment
Ние показваме отношенията между потребители на страниците на профилите. Например общи приятели, последни действия, състояние на приятелство между тези потребители и т.н. Така че кеширането ще бъде за всеки потребител и ако потребителят не види промените веднага, потребителското изживяване се отразява негативно. - person faraklit; 14.04.2011
comment
Все още е възможно да кешира тази информация, просто трябва да настроите кода, който управлява тези взаимоотношения, за да го накара да изчисти специфичните за потребителя кешове, когато нещо се промени. Не е много трудно и ще видите спад в натоварването на вашия сървър(и) и печалба в производителността за вашите потребители. Вашите потребители ще продължат да виждат свежо съдържание, но когато няма свежо съдържание, вие печелите предимството на намаленото натоварване, а потребителите ви получават предимството на незабавното съдържание. - person Phillip B Oldham; 14.04.2011
comment
Имах проблеми с unix сокети и FPM. Въпреки това имам само 1 FPM процес (като плаката на този въпрос). @unplugged, не се ли сблъсквате с тези проблеми поради съотношението на FPM процесите към децата? serverfault.com/questions/128800 / и forum.nginx.org/read.php? 3,97959,page=2 обсъждат проблемите с nginx, fastcgi и сокети. - person rynop; 27.09.2011
comment
@unpluggd съжалявам, че донесох тази стара тема. Но имам някои въпроси относно този ред Secondly, you've only got one PHP process running with lots of children. Какво означава под php процес? как да разбера колко процеси имам в момента? - person jaypabs; 04.07.2013