Nginx + PHP-FPM — иногда показываются пустые страницы?

Question

[Aleks_ja]

Столкнулись со странной проблемой — периодически отдаются пустые страницы.



Эррор логи — молчат, как будто всё отлично.



Access лог выглядит следующим образом: my.ip.address. — - [29/May/2013:16:24:25 +0100] «GET /my_page_url/ HTTP/1.1» 200 5 "/my_page_url/" «Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0»rv:21.0) Gecko/20100101 Firefox/21.0"



Т.е. вернулся статус 200, а длина контента всего 5!



Проблема либо сама прекращается со временем. Либо сразу после рестарта php-fpm. Т.е. как мы поняли — это именно php-fpm.



Версии софта такие:

RedHat 5.8

PHP 5.3.24 (fpm-fcgi) (built: Apr 12 2013 10:13:38)

Nginx nginx/0.8.55



Что это может быть?

Answer 1

[6uxou]

Проверьте конфиги самого NGINX и его хоста. Возможно ошибка кроется там.

Стоит так же спросить, вы пытаетесь вызвать в my_page_url обычную статическую HTML'ку или же PHP скрипт? Если первое — то проблема в самом NGINX/Конфигурации.

Comments

[Aleks_ja]

Там php скрипт.

Кроме того, перешли на nginx именно потому что апач на некоторых статичных страничках подвисал (долго очень грузил).

Answer 2

[6uxou]

Попробуйте с такой конфигурацией:

server {
	server_name  moysait.ru;
	
  # opt-in to the future  
	charset utf-8;
  add_header "X-UA-Compatible" "IE=Edge,chrome=1";
  
  root  /var/www/moysait.ru/httpdocs;

  location / {
    index  index.html index.htm index.php;
    try_files $uri $uri/ /index.php?q=$uri&$args;
  }

  location ~ \.php$ {
    try_files  $uri = 404;
    fastcgi_pass unix:/tmp/php.sock;
    fastcgi_index index.php;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
  }
}

ПС: Только пути поменять не забудьте. Если не получится, пишите в личку, помогу.

Answer 3

[crazyASD]

Не хватает обработчиков php-fpm по видимости. Увеличивайте, либо сокращайте количество коннектов nginx-у

Comments

[6uxou]

Если бы нехватало обработчиков, то ошибка была бы скорее всего «502 Bad Gateway» или аналогичная.

[Aleks_ja]

Колличество обработчиков пробовали увеличивать. И верно — где же ошибка?

Answer 4

[Андрей Буров]

а посмотрите dmesg может процессы FPM падают…

Comments

[Aleks_ja]

dmesg выдаёт кучу сегфолтов:

php-fpm[6898]: segfault at 00000002ecdba1c1 rip 000000000064cbd9 rsp 00007ffff69a6140 error 4
php-fpm[6902]: segfault at 0000000333638a21 rip 000000000064cbd9 rsp 00007ffff69a6040 error 4
php-fpm[25373]: segfault at 00000002ec6d5f11 rip 000000000064cbd9 rsp 00007ffff69a6040 error 4
php-fpm[16110]: segfault at 00000003cb5ae421 rip 000000000064cbd9 rsp 00007fffe1217960 error 4
php-fpm[18323]: segfault at 00000003f61feb71 rip 000000000064cbd9 rsp 00007fffe1217960 error 4

[Андрей Буров]

Ну вот и причина. Пересоберите/обновите php-fpm

[6uxou]

Удивляет честно говоря то, что при запросе отдаётся именно пустая страница, а не ошибка. Обычно если PHP-FPM падает или крешится, то вываливается 502 ошибка, т.к. NGINX не может до него достучаться.

[Андрей Буров]

Дык он может достучаться, начинает получать ответ и в этот момент FPM падает. соединение nginx<->FPM обрывает, nginx спокойно отдает то что получил (т.е. ничего).
5 символов это Chunked ответ.

[Aleks_ja]

А возможно как-то узнать из-за чего именно падает? Т.к. есть подозрение, что что-то не так с железом… Вначале апач, теперь nginx…

[Андрей Буров]

возможно, но это очень интимный вопрос (тонкий) смотреть надо

Answer 5

[6uxou]

Альтернативно:

Проверьте не только количество воркеров PHP-FPM, но и так же размеры буфферов и таймаутов FastCGI.
Вот часть конфига которую я когда-то удачно использовал в NGINX в разделе http { }:

## Size Limits
client_max_body_size          128m;
client_body_buffer_size       128k;
client_header_buffer_size     1k;
large_client_header_buffers   4 4k;

## Timeouts 
client_body_timeout   5;
client_header_timeout 5;
keepalive_timeout     5;
send_timeout          5;
#reset_timedout_connection  on; 

## General Options
ignore_invalid_headers  on;
recursive_error_pages   on;
sendfile                on;
aio                     on;
output_buffers          2 128k;
server_name_in_redirect off;
server_tokens           off;

## TCP options  
tcp_nodelay on;
tcp_nopush on;

## Compression
gzip              on;
gzip_static       on;  
gzip_proxied      any;
gzip_min_length   1;
gzip_buffers      16 8k;
gzip_comp_level   5;
gzip_http_version 1.1;
gzip_types        text/css text/javascript text/xml text/plain text/x-component application/javascript application/json application/xml application/rss+xml font/truetype font/opentype application/vnd.ms-fontobject image/svg+xml;
gzip_vary         on;
gzip_disable      "MSIE [1-6]\.";
gzip_proxied      expired no-cache no-store private auth;    

## Fast CGI
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

Надеюсь вам это поможет разобраться со своей проблемой.

Comments

[Aleks_ja]

У нас в конфиге вот так:

client_max_body_size 500m;                                                                                                                             
        client_body_buffer_size 128k;                                                                                                                          
        client_header_buffer_size 8m;                                                                                                                          
        proxy_connect_timeout 1800;                                                                                                                            
        proxy_send_timeout 1800;                                                                                                                               
        proxy_read_timeout 1800;                                                                                                                               
        proxy_buffer_size 1024k;                                                                                                                               
        proxy_buffers 4 1024k;                                                                                                                                 
        proxy_busy_buffers_size 1024k;                                                                                                                         
        proxy_temp_file_write_size 1024k;                                                                                                                      
                                                                                                                                                               
        large_client_header_buffers  40 1024k; 

Но это делали для того, чтобы в пост могло приходить много параметров и куча данных. Могло это как-то повлиять?

Хотя, вроде как, до какого-то из апгрэйдов редхата — всё работало с таким конфигом нормально.

[6uxou]

Заметил, что у вас стоит «proxy_». Если мне не изменяет память и я не ошибаюсь, то директивы «proxy_» используются в том случае, если у вас на фронте стоит NGINX, а на бекенде Apache. Если же у вас стоит только NGINX, то надо использовать директивы «fastcgi_», т.к. именно ими вы управляете последующей конфигурацией обработчика PHP-FPM(FastCGI).

Попробуйте конфиг что я дал выше. Если «любой» PHP скрипт отобразится, то будет уже над чем подумать. Если же нет, то возможно стоит пересобрать NGINX+PHP-FPM и тестировать с «голой» конфигурацией чтобы понять в чём причина.

Полный пример конфига найдёте тут: wiki.nginx.org/FullExample

Надеюсь информация была полезной.

[Aleks_ja]

К сожалению, проблема появляется только на лайве. Да и то не всегда. Поэтому тестирование конфигов затруднено. И это скорее запасной вариант. Но всеравно спасибо, будем думать каким путем пойти.

Про proxy — это лишь директивы, которые нужны, чтобы POST большой слать. Сам же php-fpm подключен стандартно через fast cgi.