Clearing nginx cache files doesn't always work

Question

I am running the nginx + PHP webservices API. I use nginx fastcgi_cache to cache all GET requests, and when some resources are updated, I clear one or more related cached resources.

The method I use for this is to calculate the nginx cache file name for each resource that I want to clear and then delete this file. For the most part, this works well.

However, I found that sometimes even after deleting the cache file, nginx will still return data from the cache.

This is not a problem with choosing the right cache file to delete - as part of my testing, I deleted the entire cache directory, and nginx still returns HIT responses

Does anyone know why this might happen? Is it possible that a different cache is involved? For example, could it be that the OS returns a cached version of the cache file in nginx, so nginx does not know that it was deleted?

I run this on CentOS and with this nginx configuration (minus the irrelevant parts):

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; } } } 

Now, when I look at this, can open_file_cache parameters affect cache files?

Any ideas?

Answer 1

No, the OS does not cache files.

However, the reason for this may be that the files are not actually deleted completely until the number of links and the number of processes in which the file is open fall to zero.

unlink(2) manual page that documents the system call used by tools such as rm looks like this:

The unlink () function removes a link with a name along the path from its directory and reduces the number of links to the file to which the link refers. If this decrement reduces the number of links to the file to zero and the process does not open, all resources associated with the file will be restored. If one or several processes open the file when the last link is deleted, the link is deleted, but the file is delayed until all links to it are closed.

Depending on the system, you can completely restore such open files completely without data loss, for example, see https://unix.stackexchange.com/questions/61820/how-can-i-access-a-deleted-open-file- on-linux-output-of-a-running-crontab-task .

Thus, truly open_file_cache effectively prevent your deletion from any consequences in processes that still have corresponding file descriptors in their cache. You can use the shorter open_file_cache_valid if urgent cleanup after removal is very important to you.

Answer 2

Make sure your browser does not cache pages. Try selecting the "Disable cache" option in the browser console and open the console when testing the server for caching.