dneichev
@dneichev
NOC Engineer in CamoIT

Странное поведение nginx + php7.0-fpm на Ubuntu 16.04. Что это может быть?

Странности проявляются в следующем:
- сайт работает какое-либо время, время всегда разное, работает достаточно шустро и без проблем
- спустя какое то время *26481 recv() failed (104: Connection reset by peer) while reading response header from upstream по логам Nginxa
- ребутим php-fpm и все заново начинает работать нормально до следующего раза
конфиги хоста в nginx

server {
	listen 80;
	server_name ;
	return 301 https://$server_name$request_uri;
}
 server {
        charset utf-8;
        client_max_body_size 128M;

        autoindex on;
	server_tokens off;

        listen 443 ssl;

	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;	
	ssl_protocols TLSv1.2;
	ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
	ssl_prefer_server_ciphers on;
	add_header Strict-Transport-Security "max-age=15768000";
	ssl_stapling on;
	ssl_stapling_verify on;	

	location / {
	        try_files $uri $uri/ /index.php?$args;
                proxy_connect_timeout 300;
                proxy_send_timeout   600;
                proxy_read_timeout   600;
                proxy_buffer_size    64k;
                proxy_buffers     16 32k;
                proxy_busy_buffers_size 64k;
                proxy_temp_file_write_size 64k;
                proxy_pass_header Set-Cookie;
                proxy_redirect     off;
                proxy_hide_header  Vary;
                proxy_set_header   Accept-Encoding '';
                proxy_ignore_headers Cache-Control Expires;
                proxy_set_header   Referer $http_referer;
                proxy_set_header   Host   $host;
                proxy_set_header   Cookie $http_cookie;
                proxy_set_header   X-Real-IP  $remote_addr;
                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                #fastcgi_pass unix:/run/php/php7.0-fpm.sock;
		fastcgi_pass 127.0.0.1:9000;
		fastcgi_read_timeout 300;
        }

	#ENABLE GZIP
	gzip on;
	gzip_disable "msie6";
	gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
	gzip_comp_level 5;

	#ENABLE BROWSER CACHE
	location ~* ^.+\.(woff|rss|atom|jpg|jpeg|gif|png|ico|rtf)$ {
		expires max;
	}

	location ~ /.well-known {
                allow all;
        }
}

в настройках fpm/www.conf ничего не менялось кроме
;listen = /run/php/php7.0-fpm.sock
listen = 127.0.0.1:9000


в slow логе fpm после краша пишет index.php, тот что вызывается виртуал хостом nginxa.
Тюнинговать fpm и тайм ауйты пробовал. Результата не дало.
Кто может сталкивался с таким, как победили? Помогите пожалуйста
  • Вопрос задан
  • 667 просмотров
Решения вопроса 1
dneichev
@dneichev Автор вопроса
NOC Engineer in CamoIT
вопрос закрыли. нашли говнокод одного из разработчиков, который зацикливал бэкэнд, в следствии чего не было выхода из процедуры и fpm не понимал что ему делать. всем спасибо за внимание
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@backender_ru
https://backender.ru/
Была такая проблема, когда FPM ложился рандомно на VPS с Debian. При этом количество процессов и так далее не помогали. Не поверите - удалил xDebug и проблем больше не было. Но это в моем случае.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

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