Nginx + PHP Servidores FPM + MYSQL diminuindo quando há muito tráfego

1

Atualmente, temos alguns servidores hospedando uma plataforma de comércio eletrônico na Digital Ocean, tentamos otimizar o quanto conseguimos, mas não foi suficiente, o site está diminuindo quando há muito tráfego, como 800 a 1000 usuários. Atualmente, achamos que é a API que está diminuindo. O erro é:

2017/11/23 14:20:51 [error] 26784 # 26784: * 126599 connect () para unix: /var/run/php/php7.0-fpm.sock failed (11: Recurso temporariamente indisponível) durante a conexão ao upstream, cliente: {ip ...}, servidor: www ..... com.br, request: "GET / ....", upstream: "fastcgi: // unix: / var / run /php/php7.0-fpm.sock: ", host:" www ...... com.br "

Atualmente, temos:

Servidor front-end:

4 núcleos, 8 gb de ram - executando nginx 1.10.3 e php fpm 7.0

servidor de API:

8 núcleos, 16 gb de ram - executando nginx 1.10.3 e php fpm 5.5.9

servidor MYSQL

MASTER + 8 ESCRAVOS (Nós não achamos que é o problema), Nós tivemos algum problema antes com números de conexão TCP / IP portas (eu não sei exatamente), mas não conseguimos resolver e criamos escravos para balanceamento de carga. Servidores estão rodando o linux ubuntu 14.04

Se mais informações forem necessárias, por favor, pergunte. Estamos lutando com isso.

Nginx conf:

worker_processes auto;
worker_rlimit_nofile 65536;
worker_connections 2048;
use epoll;
multi_accept on;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 15;
types_hash_max_size 2048;
server_names_hash_max_size 4112;
access_log off;
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 2;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;]
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 360;
fastcgi_send_timeout 360;
fastcgi_read_timeout 360;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
client_body_buffer_size    128k;
client_max_body_size       10m;
client_header_buffer_size    1k;
large_client_header_buffers  4 4k;
output_buffers   1 32k;
postpone_output  1460;
client_header_timeout  3m;
client_body_timeout    3m;
send_timeout           3m;

PHP FPM conf:

pm = on demand;
pm.max_children = 200;
pm.process_idle_timeout = 10s;
pm.max_requests = 500;

Configuração do /etc/sysctl.conf:

net.ipv4.ip_local_port_range = 2000 65535;
net.ipv4.tcp_rfc1337 = 1;
net.ipv4.tcp_fin_timeout = 15;
net.ipv4.tcp_keepalive_time = 300;
net.ipv4.tcp_keepalive_probes = 5;
net.ipv4.tcp_keepalive_intvl = 15;
net.core.rmem_default = 31457280;
net.core.rmem_max = 12582912;
net.core.wmem_default = 31457280;
net.core.wmem_max = 12582912;
net.core.somaxconn = 65535;
net.core.netdev_max_backlog = 65535;
net.core.optmem_max = 25165824;
net.ipv4.tcp_mem = 65535 131072 262144;
net.ipv4.udp_mem = 65535 131072 262144;
net.ipv4.tcp_rmem = 8192 87380 16777216;
net.ipv4.udp_rmem_min = 16384;
net.ipv4.tcp_wmem = 8192 65535 16777216;
net.ipv4.udp_wmem_min = 16384;
net.ipv4.tcp_max_tw_buckets = 1440000;
net.ipv4.tcp_tw_recycle = 1;
net.ipv4.tcp_tw_reuse = 1;
    
por Gabriel de Souza 24.11.2017 / 13:04

1 resposta

0

O recurso temporariamente indisponível indica claramente que você tem o afunilamento nos servidores front-end (nos servidores que estão registrando esse erro), nem mesmo os da API. Este erro geralmente indica a falta de memória de algum tipo ou algum limite de acerto (as conexões TCP, por exemplo), então você precisa investigar mais - a falta de informação não deixa muito espaço para suposições.

Observe também que 200 trabalhadores em 4 ou até 8 núcleos são geralmente um exagero (a menos que você tenha uma aplicação lenta e incômoda, que não é o caso em 95% das configurações, porque é um problema por si só) e php 5.5.9 não é suportado e é inseguro. Isso não tem nada a ver com o problema que você está enfrentando, mas esses problemas são menores (e no caso de problemas com o PHP) também.

    
por 26.11.2017 / 15:51