¿La política de eliminación de caché LRU de nginx es persistente tras los reinicios?

¿La política de eliminación de caché LRU de nginx es persistente tras los reinicios?

En el documento dice "

max establece el número máximo de elementos en el caché; en caso de desbordamiento de caché, se eliminan los elementos utilizados menos recientemente (LRU);

¿Es persistente tras los reinicios de nginx o del servidor?

Me pregunto cómo se rastrea esto. ¿En memoria? ¿O tal vez usando la marca de tiempo del último acceso del sistema de archivos?

No puedo encontrar ninguna información sobre eso.

¿Cómo es la información si no se puede determinar el archivo LRU (debido a un reinicio)?

Editar:

Conozco el proceso del cargador de caché de nginx. Si no fuera por ese proceso, los archivos de caché no serían persistentes en absoluto.

Según la documentación, este proceso de carga también incluye los metadatos, sin ser más específico sobre qué son los metadatos.

La pregunta es, ¿estos metadatos también incluyen la marca de tiempo del último acceso?

Sin embargo: para que esté contenido, primero debe escribirse.

Configuré un inotifywait en un archivo y lo solicité. Esto es lo que resulta de la solicitud HTTP a un archivo de caché:

cache-filename OPEN 
cache-filename ACCESS 
cache-filename CLOSE_NOWRITE,CLOSE 

Parece que no se produce ninguna modificación del archivo, lo que lleva a la conclusión preliminar de que los datos LRU no se escriben en el disco y, por lo tanto, no son persistentes.

Pero: los datos aún podrían escribirse en otro lugar. También podría escribirse desde la RAM al disco (en los archivos de caché) mediante otro proceso posterior. Por lo tanto, los datos son persistentes, pero no se garantiza que estén actualizados en el disco.

Lo que aún deja la pregunta sin respuesta.

Respuesta1

Parece que nginx puede usar el tiempo de acceso al archivo para indicar qué a LRU. Al inspeccionar el atime en una flota de servidores, algunos de los cuales están particionados con cachés más pequeños que otros debido a otro uso del disco, parece que los servidores con cachés más pequeños y más presión LRU no tienen archivos con una antigüedad determinada según lo medido por atime (-amin en encontrar). El comando que usé para ver esto es:

for i in `seq 1000 100 4000`; do 
    echo -n "Files accessed more than $i minutes ago: "
    find /opt/nginx-cache/data -type f -amin +$i | wc -l
done

Y la salida de uno de nuestros servidores:

Files accessed more than 1000 minutes ago: 52154
Files accessed more than 1100 minutes ago: 40582
Files accessed more than 1200 minutes ago: 25527
Files accessed more than 1300 minutes ago: 19567
Files accessed more than 1400 minutes ago: 13384
Files accessed more than 1500 minutes ago: 7683
Files accessed more than 1600 minutes ago: 4597
Files accessed more than 1700 minutes ago: 3038
Files accessed more than 1800 minutes ago: 1916
Files accessed more than 1900 minutes ago: 1251
Files accessed more than 2000 minutes ago: 837
Files accessed more than 2100 minutes ago: 585
Files accessed more than 2200 minutes ago: 459
Files accessed more than 2300 minutes ago: 365
Files accessed more than 2400 minutes ago: 258
Files accessed more than 2500 minutes ago: 101
Files accessed more than 2600 minutes ago: 8
Files accessed more than 2700 minutes ago: 0
Files accessed more than 2800 minutes ago: 0
Files accessed more than 2900 minutes ago: 0
Files accessed more than 3000 minutes ago: 0

Si esto es correcto, entonces el cargador de caché probablemente lee la hora de los archivos al reiniciar para eliminar correctamente los archivos LRU según sea necesario.

Respuesta2

Este documentohttp://czerasz.com/2015/03/30/nginx-caching-tutorial/describe que existe un proceso llamado "Cargador de caché". Se ejecuta solo una vez (al inicio) y carga los metadatos en la zona de memoria. Se ejecuta en iteraciones hasta que se cargan todas las claves.

información relacionada