How to fix "recv() failed (104: Connection reset by peer) 502" error in php-fpm/nginx?

Question

PHP

Hello. There is a fastvps.ru/dedicated EX-4 server, Debian-70-wheezy-64 OS is installed. One main site is spinning, on a bunch of nginx and php-fpm. If you load the site with literally 10 streams of the Siege test, then errors start to fall into the log:
readv() failed (104: Connection reset by peer) while reading upstream
recv() failed (104: Connection reset by peer) while reading response
Optcache is enabled. Help me figure out what's wrong with the configs? Apparently, it's in php-fpm.
php-fpm config:
cosmopolite.ru/php_fpm.txt
nginx config:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
  worker_connections 768;
}

http {

  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;

  proxy_read_timeout 500;
  proxy_connect_timeout 500;
  client_max_body_size 100M;
  server_names_hash_bucket_size 64;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
  include /usr/local/ispmgr/etc/nginx.domain;

}

Answer 1

Siege disconnected while nginx was receiving data from php-fpm or whatever you have in /etc/nginx/conf.d/*.conf;
Start with tests without php, make a directory with a simple index.html and send it there. If the errors remain, it's the number of handlers: 4 processes of 768 are slower than 1 process with 3072 sockets on modern hardware. Raise worker_connections to at least 2048.
Further with backlog
Through sysctl net.core.somaxconn find out the backlog value, if it is less than the worker_connections parameter, then increase it in sysctl.conf to the value = worker_connections Specify
the same value in fpm listen.backlog

Answer 2

Try in the fpm pool config to set

pm = static
pm.max_children = 60

and see if it affects your test in a positive way.
If so, then you need to adjust the values ​​of
pm.max_children \ pm.max_spare_servers in dynamic mode.
Their values ​​will depend on your load profile, how uniform it is or vice versa "peak".
Why don't you like static ? As I can see, you have 16GB of RAM on the server, the workers in the "empty" state will not take much.

Answer 3

There was such a problem. Decided by setting the correct owner on the files

sudo chown -R www-data:www-data /var/www/mysite.com

Answer 4

The problem is wider than it seems:
You need to understand what this means - php fell off
it can fall off for several reasons:
1) limits in php.ini itself - the first of them is the execution time of the php script
2) socket (connect) retention limits php-fpm
3 settings ) limits for waiting for a response from php-fpm from nginx
4) all processes are busy (died)
And when all the timeouts are correctly configured and you don't have any scripts running for a very long time - then all the chiki bunches.
It is necessary to tune all these 4 components at the same time, I understand the interaction.