nginx कैश फ़ाइलों को पर्जिंग हमेशा काम नहीं करता

Question

मैं एक nginx सर्वर + PHP webservices एपीआई चलाता हूं। मैं सभी GET अनुरोधों को कैश करने के लिए nginx के fastcgi_cache का उपयोग करता हूं, और जब कुछ संसाधन अपडेट होते हैं, तो मैं एक या अधिक संबंधित कैश संसाधनों को शुद्ध करता हूं।

जिस विधि का मैं उपयोग करने के लिए उपयोग कर रहा हूं वह प्रत्येक संसाधन के लिए nginx कैश फ़ाइल नाम की गणना करना है जिसे मैं शुद्ध करना चाहता हूं, और फिर उस फ़ाइल को हटा रहा हूं। अधिकांश भाग के लिए, यह अच्छी तरह से काम करता है।

हालांकि, मैंने पाया है कि कभी-कभी, कैश फ़ाइल हटा दिए जाने के बाद भी, nginx अभी भी कैश से डेटा वापस कर देगा।

यह नष्ट करने के लिए सही कैश फ़ाइल का चयन के साथ एक समस्या नहीं है - मेरी परीक्षण के हिस्से के रूप में, मैं पूरे कैश निर्देशिका हटा दिया हो, और nginx अभी भी हिट प्रतिक्रियाएं देता है

किसी के बारे में पता है यह क्यों हो रहा है? क्या यह संभव है कि एक और कैश शामिल है? उदाहरण के लिए, क्या यह हो सकता है कि ओएस कैश फ़ाइल के कैश किए गए संस्करण को nginx पर वापस कर रहा है, इसलिए nginx को पता नहीं है कि इसे हटा दिया गया है?

मैं CentOS पर इस चल रहा हूँ, और इस nginx config (ऋण अप्रासंगिक भागों) के साथ:

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

अब जब कि मैं इसे देखो, open_file_cache मापदंडों कैश फ़ाइलों को प्रभावित करने वाले हो सकता है?

कोई विचार?

Answer 1

नहीं, ओएस फाइलों को कैश नहीं करता है।

हालांकि, ऐसा होने का कारण यह है कि फ़ाइलों को वास्तव में पूरी तरह से हटाया नहीं जाता है जब तक कि दोनों लिंक गिनती न हो और दोनों फाइलें खोलने वाली प्रक्रियाओं की संख्या शून्य हो जाएं।

unlink(2) manual page, जो system callrm जैसे उपकरणों के द्वारा प्रयोग किया दस्तावेजों, के रूप में पढ़ता:

को अनलिंक() फ़ंक्शन लिंक अपनी निर्देशिका से पथ द्वारा नामित दूर करता है और के लिंक गणना decrements फ़ाइल जो संदर्भ द्वारा संदर्भित किया गया था। यदि वह कमी फ़ाइल की लिंक गिनती को शून्य तक कम कर देती है, और फ़ाइल को खोलने के लिए कोई प्रक्रिया नहीं है, तो फ़ाइल से जुड़े सभी संसाधन पुनः दावा किए जाते हैं। यदि अंतिम लिंक हटा दिए जाने पर एक या अधिक प्रक्रियाओं में फ़ाइल खुलती है, तो लिंक हटा दिया जाता है, लेकिन फ़ाइल को हटाने में देरी हो जाती है जब तक कि इसके सभी संदर्भ बंद नहीं हो जाते हैं।

सिस्टम के आधार पर, आप वास्तव में किसी भी डेटा हानि के बिना पूरी तरह से ऐसी खुली फ़ाइलों को पुनर्प्राप्त कर सकते हैं, उदाहरण के लिए, https://unix.stackexchange.com/questions/61820/how-can-i-access-a-deleted-open-file-on-linux-output-of-a-running-crontab-task देखें।

तो, वास्तव में, open_file_cache प्रभावी ढंग से उन प्रक्रियाओं में कोई प्रभाव होने से आपके विलोपन को रोक देगा जो अभी भी उनके कैश में प्रासंगिक फ़ाइल वर्णनकर्ता हैं। यदि आप हटाने के बाद तत्काल शुद्धीकरण आपके लिए बहुत महत्वपूर्ण हैं तो आप एक छोटे open_file_cache_valid का उपयोग करना चाह सकते हैं।

Answer 2

सुनिश्चित करें कि आपका ब्राउज़र पृष्ठों को कैश नहीं कर रहा है। ब्राउज़र कंसोल के तहत अक्षम कैश विकल्प का चयन करने का प्रयास करें और कैशिंग के लिए अपने सर्वर का परीक्षण करते समय कंसोल खोलें।