504 Gateway Time-out during POST

Maybe not related but… when I tried to run phpMyAdmin under php-fpm
and mysqli (notice it is a problem with MySQLi), I was getting random
and very often 504 errors because the php was sigfaulting. I am pretty
sure it is not an nginx problem but more the fact that you have PHP
now running as fastcgi rather than mod_php.

Please, take a closer look at nginx’s error log and if the server is
not in production or just quickly run php-cgi without php-fpm like
this:

php-cgi -b 127.0.0.1:9000

Do not make it go in daemon mode so that you can see on the console if
it dies.

HTH,
Kiril

On Son 07.09.2008 21:30, David wrote:

It’s vbulletin (vbulletin.org)

BTW just a thought I had when looking at my php.ini …

I moved my MySQL to a different drive and moved my mysql.sock In
php.ini it looks like it’s looking at the wrong one, and
/var/lib/mysql/mysql.ini which I thought was symlinked but it’s
not. Could this be causing the speed problem ?

I don’t think so.

Do you have any information about the timing :wink:

I now have this in my nginx.conf is this what you meant ? Does this log
to the
same error_log ?

log_format  main  '$remote_addr - $remote_user [$time_local] 

$request ’
'"$status" $body_bytes_sent “$http_referer” ’
‘"$http_user_agent" “$http_x_forwarded_for”’;

log_format timing '$remote_addr - $remote_user [$time_local] $request ’
'upstream_response_time $upstream_response_time ’
‘msec $msec request_time $request_time’;

vbulletin.com

On Son 07.09.2008 21:58, David wrote:

I now have this in my nginx.conf is this what you meant ? Does this log to the
same error_log ?

log_format main '$remote_addr - $remote_user [$time_local] $request ’
'"$status" $body_bytes_sent “$http_referer” ’
‘"$http_user_agent" “$http_x_forwarded_for”’;

log_format timing '$remote_addr - $remote_user [$time_local] $request ’
'upstream_response_time $upstream_response_time ’
‘msec $msec request_time $request_time’;

No you need to add this line in nginxs config file and send a HUP to the
master process

access_log logs/timing.log timing;

On Son 07.09.2008 22:19, David wrote:

This didn’t resort in a 504 but was a situation I can replicate over
and over with the server on 0.4 load averages:

xxx.xxx.xxx.xxx - - [07/Sep/2008:17:16:54 -0500] POST
/forums/private.php?do=insertpm&pmid=101373 HTTP/1.1
upstream_response_time 37.832 msec 1220825814.697 request_time 37.833

Ok please can you increse the

max_execution_time = 40

to

max_execution_time = 80

add error_reporting = E_ALL

in php.ini and restart php-fm

and please can you add

$status

after

[$time_local]

I have done all that you asked.

Very, very, rarely that script will execute (it’s just sending a private
message
to another user) as it should - basically instantly.

I see sometimes fastcgi is logging the

I have just managed to recreate the 504 error and I can see no errors in
my
php-error-log file.

The 504 occured here:

[07/Sep/2008:17:44:24 -0500] 504 POST
/forums/private.php?do=insertpm&pmid=101373 HTTP/1.1
upstream_response_time
60.000 msec 1220827464.227 request_time 60.003

and in the nginx error_log:

30104#0: *43481 upstream timed out (110: Connection timed out) while
reading
response header from upstream, client

This didn’t resort in a 504 but was a situation I can replicate over and
over
with the server on 0.4 load averages:

xxx.xxx.xxx.xxx - - [07/Sep/2008:17:16:54 -0500] POST
/forums/private.php?do=insertpm&pmid=101373 HTTP/1.1
upstream_response_time
37.832 msec 1220825814.697 request_time 37.833

Also getting a lot of these:

Sep 07 17:16:00.585206 [WARNING] fpm_children_bury(), line 229: child
27767
(pool default) exited on signal 15 SIGTERM after 4734.359086 seconds
Sep 07 17:16:00.585350 [WARNING] fpm_children_bury(), line 229: child
27770
(pool default) exited on signal 15 SIGTERM after 4734.355287 seconds
Sep 07 17:16:00.585452 [WARNING] fpm_children_bury(), line 229: child
27772
(pool default) exited on signal 15 SIGTERM after 4734.352343 seconds

I sometimes get these:

an upstream response is buffered to a temporary file
/usr/local/nginx/fastcgi_temp/0/00/0000000000 while reading upstream

On Mon 08.09.2008 10:24, Kiril A. wrote:

Try posting also to the PHP-FPM list. The author of PHP-FPM is very
well familiar with nginx and will be able to help you out here.

full ack

Try posting also to the PHP-FPM list. The author of PHP-FPM is very
well familiar with nginx and will be able to help you out here.

Kiril

On Son 07.09.2008 22:47, David wrote:

The 504 occured here:

[07/Sep/2008:17:44:24 -0500] 504 POST
/forums/private.php?do=insertpm&pmid=101373 HTTP/1.1 upstream_response_time
60.000 msec 1220827464.227 request_time 60.003

You see here first the 40s in php.ini and now the 60s in php-fm config
kills the process.

Please can you try to find out how long the task should run normaly!

You can try to set both values (request_execution_timeout,
max_execution_time) to a high value and see how long the task run
normally

Aleks

You may want to try using spawn-fcgi just as a test to see if behaviour
changes.
Chris:)

Thank you Kiril, I’ll do that. I wasn’t sure whether this was stricly an
nginx
or php-fpm issue, but it does sound more PHP related.

Aleksander,

You mentioned about securing php.ini and referred to:

http://www.php.net/manual/en/session.configuration.php#ini.session.save-path
http://www.php.net/manual/en/session.configuration.php#ini.session.entropy-file

Can you please advise what these should be set to ?

Thanks

Dear David,

I think this is now ot. I switch to personal mail.

On Mon 08.09.2008 19:13, David wrote:

Aleksander,

You mentioned about securing php.ini and referred to:

PHP: Runtime Configuration - Manual
PHP: Runtime Configuration - Manual

Can you please advise what these should be set to ?

On Mon 08.09.2008 13:00, [email protected] wrote:

hei guys
do post your final findings here on how u fixed the problems!

Yes

Just an update …

Whilst I feel it may be too early to say this is resolved, I have made a
lot of
progress.

Tidying up the order of my sections in nginx.conf appears to
have
made the PHP execute as quickly as it should.

I’m going to give this a couple more days and will update in more detail
should
things stay as good as they are now.

Thanks again all for your help.

hei guys
do post your final findings here on how u fixed the problems!