[Nginx] upstream timed out (110: Connection timed out) while reading response header from upstream
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.
$ 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.
That’s all from the Gemba.