caching php-fpm - Nginx y / o php5-fpm recuerda el directorio raíz enlazado




tuning windows (4)

Una vez que modifiqué el realpath_cache_ttl a '2' (Eso debería arreglarlo) aún se mostraba el contenido incorrecto.

Después de investigar en los mods cargados para php-fpm, descubrí que opcache estaba funcionando. Deshabilitar eso borrará el camino real en caché cuando termine el ttl.

No quiero bajar demasiado el cache de la memoria caché realpath, así que me instalaré con una recarga de php-fpm, ya que es gracioso. Espero que este hilo y mis respuestas ayuden a otros;)

Mi raíz del sitio nginx apunta a un enlace simbólico. Si modifico el enlace simbólico (también conocido como implementar una nueva versión del sitio web), la versión anterior del script php sigue apareciendo. Eso huele a caché, o un error.

Primero parecía que Nginx estaba almacenando en caché el dir enlazado, pero recargar / reiniciar / matar y comenzar nginx no lo solucionó, así que reinicié php5-fpm - esto solucionó mi problema.

Pero no quiero reiniciar nginx y / o php5-fpm después de una implementación: quiero saber por qué hay tal caché (o error) y por qué no funcionó correctamente.

Información útil:

  • Sistema operativo: Ubuntu 13.10 (GNU / Linux 3.8.0-19-generic x86_64)
  • Nginx: vía ppa: nginx / estable
  • PHP: a través de ppa: ondrej / php5 (php5-fpm)

Configuración del sitio Nginx:

root /home/rob/sandbox/deploy/public/;
index index.php index.html index.htm;
location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass php;
}

Configuración del servidor Nginx (en parte, el resto es por defecto):

http {
    sendfile off;
    upstream php {
        server unix:/var/run/php5-fpm.sock;
    }
}

Árbol para / home / rob / sandbox:

├── deploy -> web2
├── web1
│   └── public
│       └── index.php (echo ONE)
└── web2
    └── public
        └── index.php (echo TWO)
  • solicitud: http://localhost/index.php
  • respuesta esperada: DOS
  • respuesta real: ONE

Parte de la salida de realpath_cache_get()

[/home/rob/sandbox/deploy/public/index.php] => Array (
    [key] => 1.4538996210143E+19
    [is_dir] => 
    [realpath] => /home/rob/sandbox/web2/public/index.php
    [expires] => 1383730041
)

Entonces, esto significa que deploy/public/index.php está correctamente vinculado a web2/public/index.php , ¿verdad? Bueno, incluso con las rutas correctas en la lista realpath_cache, la respuesta aún es UNA.

Después de rm deploy y ln -s web2 deploy se reinició Nginx, sin efecto. Reiniciar php5-fpm después de esto da la respuesta esperada de 'DOS'.

Es bueno saber que junto a los archivos index.php, hice algunas pruebas con los archivos .css y .js. Después de eliminar y volver a crear el enlace simbólico de / a web1 y web2, nginx responderá con el contenido correcto de los archivos.

¿Qué extrañé, qué no estoy viendo?


Tenía exactamente el mismo problema y ninguno de los trucos ayudó. Además de todos los trucos enumerados en esta página, me aseguré de que opcache esté deshabilitado, luego nginx caché también estaba deshabilitado. lo puse

sendfile off;

Fue descrito en algún lugar en .

Empecé a usar strap php y nginx, y resultó que algunas bibliotecas son leídas en una nueva ubicación, pero también algunas se leyeron desde OLD location a las que ya no apunta el enlace simbólico. Además de eso, la actualización de la secuencia de comandos php dentro del directorio OLD siempre se mostraba correctamente, por lo que no se parecía a la caché. Para hacerlo más confuso, la línea de comando funcionó bien y siguió el enlace simbólico a la NUEVA ubicación. ¡Me estaba quitando el pelo de la cabeza por esto!

Resultó que el responsable de todo esto era el caché del compositor: estaba almacenando en caché algunas bibliotecas. Sé que no todos lo usan, pero si lo haces y tienes un problema similar, vale la pena verificarlo. Tengo un proveedor al mismo nivel que las secuencias de comandos de implementación y supongo que la memoria caché del compositor estaba causando mucha confusión sobre qué ubicación debería usarse. Después de limpiarlo con

composer clear-cache

El sistema comenzó a comportarse como se esperaba.

Espero que ayude a alguien.


Configura tu nginx usando $ realpath_root. Debería ayudar.

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;

Felicitaciones a Vitaly Chirkov ( https://.com/a/23904770/219272 ).


Su mensaje de error le dice que proviene de la configuración de nginx.

client_max_body_size aumentar client_max_body_size en la nginx.conf servidor nginx.conf . p.ej :

http {
    server {
        client_max_body_size 20M;
        listen       80;
        server_name  test.com;
    }
}






caching nginx php