Несколько недель назад я заметил в инструментах Google для веб-мастеров, что некоторые из моих URL-адресов возвращают 502-е.
Один из таких URL-адресов http://www.sau.com.au/forums/topic/437438-around-the-bay-wrap-up/
Этот URL-адрес возвращает 502 для любого скина рабочего стола, но отлично работает на мобильном устройстве (другой скин)
Обратите внимание, что он очень быстро возвращает 502, указывая мне, что это не выполнение или какая-то форма тайм-аута.
Помимо нескольких подобных, все остальные URL на сайте в порядке.
Единственная запись журнала, которая может хоть как-то помочь, - это эта;
2015/06/29 09:33:39 [ошибка] 19650 # 0: * 4431763 восходящий поток преждевременно закрыл FastCGI stdout при чтении заголовка ответа от восходящего потока, клиент: 94.228.34.203, сервер: sau.com.au, запрос: "GET / форумы / topic / 437438-around-the-bay-wrap-up / HTTP / 1.1 ", восходящий поток:" fastcgi: // unix: /var/run/php-fpm/php-fpm.sock: ", host:" www.sau.com.au ", реферер:"http://www.sau.com.au/forums/forum/100-victoria/"
Я также перезапустил APC, что не помогло. Он имел фрагментацию всего на 1,5%.
Я не могу найти записей с превышением лимита. Характеристики сервера довольно высоки, поэтому PHP имеет много памяти, размеры запросов, а также большие таймауты.
Я пробовал следующее, о чем читал, но без разницы.
fastcgi_buffer_size 10240k;
fastcgi_buffers 4 10240k;
Я не хочу вносить какие-либо большие изменения, потому что это только на некоторых страницах. Один поток предложил обновить PHP до версии 5.5.
Я не знаю, где искать дополнительную помощь. Каким должен быть мой следующий шаг?
Некоторая информация;
nginx version: nginx/1.6.2
PHP 5.3.3 (fpm-fcgi) (built: Oct 30 2014 20:14:56)
ОБНОВЛЕНИЕ 1
В журнал ошибок PHP ничего не записано. Тем не менее, ведение журнала ошибок включено;
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
ОБНОВЛЕНИЕ 2
dmesg не обновляется и нет файла kernel.log;
-rw-r--r-- 1 root root 41179 Dec 18 2014 dmesg
РЕШЕНО
Я устанавливал XDebug, как предложил @ sa289 в этот ответ и для этого мне нужно было обновить PHP 5.3 до PHP 5.5. Я надеялся, что это решит проблему само по себе, но этого не произошло. Итак, я установил XDebug и добавил zend_extension в php.ini, перезапустил PHP и, вуаля, 502 исчезли. Я снова закомментировал расширение zend, и 502 вернулись. XDebug приходит на помощь. Нет твердого понимания причины или истинного решения, но для меня этого достаточно.
Я бы посмотрел, где может произойти сбой, используя Xdebug. Xdebug можно использовать для выполнения чего-то, что называется трассировкой, где он будет сообщать вам каждую строку кода, который выполняется, и таким образом вы можете увидеть последнюю строку кода, которая была запущена перед сбоем, чтобы она указала вам правильное направление. У вас может быть только трассировка, когда установлен определенный cookie, поэтому вы не создаете журналы трассировки для каждого запроса. Обратите особое внимание на следующие параметры конфигурации:
xdebug.trace_enable_triggerxdebug.trace_output_dirxdebug.collect_paramsxdebug.trace_output_name (Мне нравится "trace.% P.% T", потому что он помещает PID в имя файла, что может быть полезно в определенных случаях)Видеть http://xdebug.org/docs/all_settings для получения подробной информации об этих параметрах конфигурации, а также о других.