solucion - 502 errores de puerta de enlace en alta carga(nginx/php-fpm)

error 504 tiempo de excepción de la puerta de enlace

Question

Trabajo para un sitio de Internet bastante ocupado que a menudo recibe picos de tráfico muy grandes. Durante estos picos, se solicitan cientos de páginas por segundo y esto produce errores aleatorios de la pasarela 502.

Ahora ejecutamos Nginx (1.0.10) y PHP-FPM en una máquina con 4 unidades SAS 15k (raid10) con una CPU de 16 núcleos y 24 GB de RAM DDR3. También hacemos uso de la última versión de Xcache. El DB está ubicado en otra máquina, pero la carga de esta máquina es muy baja y no tiene problemas.

Bajo carga normal, todo funciona perfectamente, la carga del sistema es inferior a 1, y el informe de estado de PHP-FPM nunca muestra realmente más de 10 procesos activos a la vez. Siempre hay cerca de 10 GB de ram todavía disponible. Bajo carga normal, la máquina maneja aproximadamente 100 páginas vistas por segundo.

El problema surge cuando llegan enormes picos de tráfico y se solicitan cientos de páginas vistas por segundo desde la máquina. Observé que el informe de estado de FPM muestra hasta 50 procesos activos, pero eso todavía está muy por debajo de las 300 conexiones máximas que hemos configurado. Durante estos picos, el estado de Nginx informa hasta 5000 conexiones activas en lugar del promedio normal de 1000.

Información del SO: lanzamiento de CentOS 5.7 (final)

CPU: CPU Intel (R) Xeon (R) E5620 @ 2.40GH (16 núcleos)

php-fpm.conf

daemonize = yes
listen = /tmp/fpm.sock
pm = static
pm.max_children = 300
pm.max_requests = 1000

No he configurado rlimit_files, porque hasta donde sé, debería usar el sistema predeterminado si no lo hace.

fastcgi_params (solo valores agregados al archivo estándar)

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
fastcgi_pass unix:/tmp/fpm.sock;

nginx.conf

worker_processes 8;
worker_connections 16384;
sendfile on;
tcp_nopush on;
keepalive_timeout 4;

Nginx se conecta a FPM a través del zócalo Unix.

sysctl.conf

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 1
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.eth0.rp_filter=1
net.ipv4.conf.lo.rp_filter=1
net.ipv4.ip_conntrack_max = 100000

limits.conf

* soft nofile 65536
* hard nofile 65536

Estos son los resultados de los siguientes comandos:

ulimit -n
65536
ulimit -Sn
65536
ulimit -Hn
65536
cat /proc/sys/fs/file-max
2390143

Pregunta: Si PHP-FPM no se está quedando sin conexiones, la carga aún es baja, y hay mucha RAM disponible, ¿qué cuello de botella podría estar causando estos errores aleatorios de la puerta de enlace 502 durante el tráfico intenso?

Nota: por defecto, los ulimits de esta máquina eran 1024, ya que lo cambié a 65536 No reinicié completamente la máquina, ya que es una máquina de producción y significaría demasiado tiempo de inactividad.

Answer 1

@Señor. Bendición

Tengo 8 núcleos de 14 GB ram. Pero el sistema le da tiempo de espera a Gateway muy a menudo.
Implementar la solución a continuación tampoco resolvió el problema. Aún buscando mejores soluciones.

Usted tiene: fastcgi_buffers 4 256k;

Cambiarlo a:

fastcgi_buffers 256 16k; // 4096k total

Configure también fastcgi_max_temp_file_size 0, que deshabilitará el almacenamiento en búfer en el disco si las respuestas comienzan a exceder sus búferes fastcgi .

Gracias.

Answer 2

El socket de Unix acepta 128 conexiones por defecto. Es bueno poner esta línea en /etc/sysctl.conf

net.core.somaxconn = 4096

Answer 3

Esto debería arreglarlo ...

Usted tiene: fastcgi_buffers 4 256k;

Cámbielo a: fastcgi_buffers 256 16k; // 4096k total

Establezca también fastcgi_max_temp_file_size 0 , que deshabilitará el almacenamiento en búfer en el disco si las respuestas comienzan a exceder sus búferes fastcgi.

Answer 4

Si no está ayudando en algunos casos, use el enlace de puerto normal en lugar del socket, porque el socket en 300+ puede bloquear nuevas solicitudes forzando a nginx a mostrar 502.