L'eliminazione dei file della cache di nginx non funziona sempre

Question

Eseguo un server nginx + API di servizi web PHP. Uso nginx's fastcgi_cache per memorizzare nella cache tutte le richieste GET e quando alcune risorse vengono aggiornate, rimuovo una o più risorse della cache correlate.

Il metodo che sto usando per fare ciò è quello di calcolare il nome del file della cache nginx per ogni risorsa che voglio eliminare, e quindi cancellare quel file. Per la maggior parte, funziona bene.

Tuttavia, a volte ho scoperto che, anche dopo aver eliminato il file cache, nginx restituirà comunque i dati dalla cache.

Questo non è un problema con la selezione del file di cache corretto per eliminare - come parte della mia prova, ho cancellato la cartella della cache intera, e nginx restituisce comunque risposte HIT

È qualcuno a conoscenza di perché questo potrebbe accadere? È possibile che sia coinvolta un'altra cache? Ad esempio, potrebbe essere che il sistema operativo stia restituendo una versione cache del file cache a nginx, quindi nginx non è consapevole del fatto che è stato cancellato?

Io corro questo su CentOS, e con questo nginx config (meno parti irrilevanti):

user nginx; 

# Let nginx figure out the best value 
worker_processes auto; 

events { 
    worker_connections 10240; 
    multi_accept  on; 
    use     epoll; 
} 

# Maximum number of open files should be at least worker_connections * 2 
worker_rlimit_nofile 40960; 

# Enable regex JIT compiler 
pcre_jit on; 

http { 

    # TCP optimisation 
    sendfile  on; 
    tcp_nodelay  on; 
    tcp_nopush  on; 

    # Configure keep alive 
    keepalive_requests 1000; 
    keepalive_timeout 120s 120s; 

    # Configure SPDY 
    spdy_headers_comp 2; 

    # Configure global PHP cache 
    fastcgi_cache_path /var/nginx/cache levels=1:2 keys_zone=xxx:100m inactive=24h; 

    # Enable open file caching 
    open_file_cache max=10000 inactive=120s; 
    open_file_cache_valid 120s; 
    open_file_cache_min_uses 5; 
    open_file_cache_errors off; 

    server { 
     server_name xxx; 
     listen 8080; 

     # Send all dynamic content requests to the main app handler 
     if (!-f $document_root$uri) { 

      rewrite ^/(.+) /index.php/$1   last; 
      rewrite ^/  /index.php   last; 
     } 

     # Proxy PHP requests to php-fpm 
     location ~ [^/]\.php(/|$) { 

      # Enable caching 
      fastcgi_cache xxx; 

      # Only cache GET and HEAD responses 
      fastcgi_cache_methods GET HEAD; 

      # Caching is off by default, an can only be enabled using Cache-Control response headers 
      fastcgi_cache_valid 0; 

      # Allow only one identical request to be forwarded (others will get a stale response) 
      fastcgi_cache_lock on; 

      # Define conditions for which stale content will be returned 
      fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503; 

      # Define cache key to uniquely identify cached objects 
      fastcgi_cache_key "$scheme$request_method$host$request_uri"; 

      # Add a header to response to indicate cache results 
      add_header X-Cache $upstream_cache_status; 

      # Configure standard server parameters 
      fastcgi_split_path_info ^(.+\.php)(/.+)$; 
      include fastcgi_params; 

      # php-fpm config 
      fastcgi_param SCRIPT_URL  $fastcgi_path_info; 
      fastcgi_param PATH_INFO   $fastcgi_path_info; 
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
      fastcgi_param REQUEST_SCHEME $scheme; 
      fastcgi_param REMOTE_USER  $remote_user; 

      # Read buffer sizes 
      fastcgi_buffer_size 128k; 
      fastcgi_buffers 256 16k; 
      fastcgi_busy_buffers_size 256k; 
      fastcgi_temp_file_write_size 256k; 

      # Keep connection open to enable keep-alive 
      fastcgi_keep_conn on; 

      # Proxy to PHP 
      fastcgi_pass unix:/var/run/php-fpm/fpm.sock; 
     } 
    } 
} 

Ora che guardo questo, potrebbe essere i parametri open_file_cache che colpisce i file della cache?

Qualche idea?

Answer 1

No, il sistema operativo non memorizza i file nella cache.

Tuttavia, il motivo per cui questo potrebbe accadere è che i file non vengono effettivamente eliminati completamente fino a quando sia il conteggio dei collegamenti sia il numero di processi con il file aperto si riducono entrambi a zero.

Il unlink(2) manual page, che documenta la system call usata da strumenti come rm, recita:

Il scollegali() funzione rimuove il collegamento nominato dal percorso dalla sua directory e decrementa il conteggio dei collegamenti del file a cui è stato fatto riferimento dal collegamento. Se tale decremento riduce a zero il conteggio dei collegamenti del file e nessun processo ha il file aperto, tutte le risorse associate al file vengono recuperate. Se uno o più processi hanno il file aperto quando viene rimosso l'ultimo collegamento, il collegamento viene rimosso, ma la rimozione del file viene ritardata fino a quando non vengono chiusi tutti i riferimenti.

A seconda del sistema, è ancora possibile ripristinare tali file aperti completamente senza alcuna perdita di dati, ad esempio, vedere https://unix.stackexchange.com/questions/61820/how-can-i-access-a-deleted-open-file-on-linux-output-of-a-running-crontab-task.

Quindi, in effetti, open_file_cache impedirebbe effettivamente alla cancellazione di avere alcun effetto all'interno dei processi che hanno ancora descrittori di file rilevanti nella propria cache. Potresti voler usare uno open_file_cache_valid più corto se l'eliminazione urgente dopo l'eliminazione è molto importante per te.

Answer 2

Assicurarsi che il browser non stia memorizzando nella cache le pagine. Prova a selezionare l'opzione Disabilita cache nella console del browser e mantieni aperta la console durante il test del server per la memorizzazione nella cache.