[Nginx] upstream timed out (110: Connection timed out) while reading response header from upstream

Tadashi Shigeoka ·  Sat, March 28, 2015

The site codenote.net was in a state where it was difficult to connect due to 504 Gateway Time-out errors.

First, checking the Nginx error log showed the error upstream timed out (110: Connection timed out) while reading response header from upstream.

Nginx
$ tail -F /var/log/nginx/codenote.net/error.log 
2015/03/28 23:45:04 [error] 20407#0: *537270 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 223.135.69.50, server: codenote.net, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/www.sock", host: "codenote.net"

I temporarily restarted the PHP-FPM process and it was fixed for the moment, but it soon became inaccessible again.

$ service php-fpm restart
Stopping php-fpm:                                          [  OK  ]
Starting php-fpm:                                          [  OK  ]

Investigation revealed there was a problem with PHP-FPM configuration. When I checked, the process manager settings were almost at default. I thought I had configured them properly…

/etc/php-fpm.d/www.conf

Below are the default pm (process manager) settings.

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives:
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
; Note: This value is mandatory.
pm = dynamic

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes to be created when pm is set to 'dynamic'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI.
; Note: Used when pm is set to either 'static' or 'dynamic'
; Note: This value is mandatory.
pm.max_children = 9

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2
pm.start_servers = 3

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 2

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 4

; The number of requests each child process should execute before respawning.
; This can be useful to work around memory leaks in 3rd party libraries. For
; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS.
; Default Value: 0
pm.max_requests = 200

I changed to the following settings:

pm = static
pm.max_children = 30
pm.max_requests = 500

pm = static is a setting that fixes the number of child processes from the start. While dynamic is dynamic, static that can reserve resources from the beginning makes resource usage easier to understand, so I chose static.

max_children is the maximum number of child processes to start.

max_requests is the number of requests child processes execute before restarting.

After changing the PHP-FPM process manager settings, the 504 Gateway Time-out was no longer displayed and access became comfortable.

Reference Information

That’s all from the Gemba.