linux - php7 - que es<?=

Nginx y php-fpm: no pueden deshacerse de los errores 502 y 504

Question

Tengo un servidor de Ubuntu y un sitio web bastante alto cargado. El servidor es:

• Dedicado a nginx, usa php-fpm (no apache), mysql está ubicado en una máquina diferente
• Tiene 8 GB de RAM
• Obtiene alrededor de 2000 solicitudes por segundo.

Cada proceso php-fpm consume aproximadamente 65 MB de RAM, según el comando top :

Memoria libre:

admin@myserver:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          7910       7156        753          0        284       2502
-/+ buffers/cache:       4369       3540
Swap:         8099          0       8099

PROBLEMA

Últimamente, estoy experimentando grandes problemas de rendimiento. Muy grandes tiempos de respuesta, muchos tiempos de Gateway Timeouts y por la noche, cuando la carga Gateway Timeouts , el 90% de los usuarios solo ven "Servidor no encontrado" en lugar del sitio web (no puedo reproducir esto)

REGISTROS

Mi registro de errores Nginx está lleno de los siguientes mensajes:

2012/07/18 20:36:48 [error] 3451#0: *241904 upstream prematurely closed connection while reading response header from upstream, client: 178.49.30.245, server: example.net, request: request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "example.net", referrer: "http://example.net/articles"

He intentado cambiar a un socket de Unix, pero sigo teniendo esos errores:

2012/07/18 19:27:30 [crit] 2275#0: *12334 connect() to unix:/tmp/fastcgi.sock failed (2: No such file or directory) while connecting to upstream, client: 84.
237.189.45, server: example.net, request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://unix:/tmp/fastcgi.sock:", host: "example.net", referrer: "http
://example.net/articles"

Y el registro php-fpm está lleno de estos:

[18-Jul-2012 19:23:34] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there  are 0 idle, and 75 total children

He intentado aumentar los parámetros dados hasta 100 , pero aún parece no ser suficiente.

Configuraciones

Aquí está mi configuración actual

php-fpm

listen = 127.0.0.1:9001
listen.backlog = 4096
pm = dynamic
pm.max_children = 130
pm.start_servers = 40
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_requests = 100

nginx

worker_processes  4;
worker_rlimit_nofile 8192;
worker_priority 0;
worker_cpu_affinity 0001 0010 0100 1000;

error_log  /var/log/nginx_errors.log;

events {
    multi_accept off;
    worker_connections  4096;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    access_log off;
    sendfile        on;
    keepalive_timeout  65;
    gzip  on;

    # fastcgi parameters
    fastcgi_connect_timeout 120;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 1000;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_intercept_errors on;

    client_max_body_size 128M;

    server {
        server_name example.net;
        root /var/www/example/httpdocs;
        index index.php;
        charset utf-8;
        error_log /var/www/example/nginx_error.log;

        error_page 502 504 = /gateway_timeout.html;

        # rewrite rule
        location / {
            if (!-e $request_filename) {
                rewrite ^(.*)$ /index.php?path=$1 last;
            }
        }
        location ~* /.php {
            fastcgi_pass 127.0.0.1:9001;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            include fastcgi_params;
        }
    }
}

Le agradecería cualquier consejo sobre cómo identificar el problema y qué parámetros puedo ajustar para solucionarlo. ¿O tal vez 8GB de RAM no es suficiente para este tipo de carga?

Answer 1

La configuración de nginx microcache también ayudaría. Que servirá la misma respuesta durante unos segundos.

http://seravo.fi/2013/optimizing-web-server-performance-with-nginx-and-php tiene buena información sobre el rendimiento de nginx. Lo seguí personalmente y estoy bastante contento.

Answer 2

Necesito ver la configuración de php.ini y no creo que esto esté relacionado con MySQL, ya que está teniendo los errores de socket. Además, ¿esto es algo que comienza a comenzar a suceder después de un período de tiempo o sucede inmediatamente cuando el servidor se reinicia?

Intente reiniciar el daemon php5-fpm y vea qué sucede mientras sigue su registro de errores.

Verifique su archivo php.ini y también todos sus fastcgi_params que se encuentran típicamente en / etc / nginx / fastcgi_params. Hay un montón de ejemplos de lo que estás tratando de hacer.

Además, ¿tienes habilitada la extensión de caché de apc php?

Se verá así en su archivo php.ini si está en una pila de lámparas:

extension = apc.so
....
apc.enabled = 0

Probablemente no estaría de más hacer algunas pruebas de carga de conexión mysql desde la línea de comandos y ver cuáles son los resultados.

Answer 3

Una serie de cuestiones. Todavía vale la pena arreglarlos con un sitio tan ocupado. MySQL puede ser la causa raíz por ahora. Pero a más largo plazo necesitas hacer más trabajo.

Almacenamiento en caché

Veo uno de tus mensajes de error que muestra una solicitud de obtención al PHP ascendente. Esto no se ve bien con un sitio de alto tráfico (2000 r / s como usted mencionó). Esta página (/ readarticle / 121430) parece una página perfectamente almacenable. Por un lado, puede usar nginx para almacenar en caché tales páginas. Echa un vistazo a caché fastcgi

GET /readarticle/121430

php-fpm

pm.max_requests = 100

El valor significa que un proceso será eliminado por el maestro php-fpm después de atender 100 solicitudes. php-fpm usa ese valor para luchar contra las fugas de memoria de terceros. Su sitio está muy ocupado, con 2000r / s. Su máximo de procesos secundarios es 130, cada uno solo puede atender un máximo de 100 solicitudes. Eso significa que después de 13000/2000 = 6,5 segundos, todos serán reciclados. Esto es demasiado (20 procesos muertos cada segundo). Al menos debe comenzar con un valor de 1000 y aumentar ese número siempre que no vea una pérdida de memoria. Alguien usa 10.000 en producción.

nginx.conf

• Cuestión 1:

      if (!-e $request_filename) {
          rewrite ^(.*)$ /index.php?path=$1 last;
      }

  Deben ser reemplazados por archivos de prueba más eficientes:

      try_files $uri /index.php?path=$uri;

Se guarda un extra si el bloque de ubicación y una regla de reescritura de expresiones regulares coinciden.

• Problema 2: usar unix socket te ahorrará más tiempo que usar ip (alrededor del 10-20% de mi experiencia). Es por eso que php-fpm lo está usando por defecto.

• Problema 3: Es posible que le interese configurar conexiones keepalive entre nginx y php-fpm. Un ejemplo se da here en el sitio oficial de nginx.

Answer 4

por el bien de tener una respuesta para esta pregunta:

You should check your MySQL server. Probably it''s overloaded or it limits count of parallel MySQL connections. You should find the bottleneck. And according to your top screenshot it doesn''t look like either RAM or CPU, then it''s most likely I/O. - @VBrat

Cosas que podrías querer hacer en el futuro:

1- Aumenta el tamaño de tu RAM.

2- usar el caché. Vea este artículo sobre cómo el caché puede acelerar su sitio.

3- Reducir el número de consultas que se ejecutan.

Answer 5

• Configurar la extensión APC para PHP (verificar / configurar)
• MySQL - Comprobar configuración, índices, consultas lentas
• Instalar y configurar Barniz. Esto puede almacenar en caché las solicitudes de páginas y ser bastante útil para reducir la cantidad de solicitudes de php y las consultas de mysql que necesita realizar. Puede ser complicado con cookies / ssl pero por lo demás no es demasiado difícil y vale la pena correr